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Introduction and Preliminaries 


It is possible to build a cabin with no foundations, 

but not a lasting building. 

Eng. Isidor Goldreich (1906-1995) 


1.1 Introduction 

The vast expansion and rigorous treatment of cryptography is one of 
the major achievements of theoretical computer science. In particular, 
concepts such as computational indistinguishability, pseudorandomness 
and zero-knowledge interactive proofs were introduced, classical notions 
such as secure encryption and unforgeable signatures were placed on 
sound grounds, and new (unexpected) directions and connections were 
uncovered. Indeed, modern cryptography is strongly linked to complex¬ 
ity theory (in contrast to “classical” cryptography which is strongly 
related to information theory). 

Modern cryptography is concerned with the construction of infor¬ 
mation systems that are robust against malicious attempts to make 
these systems deviate from their prescribed functionality. The pre¬ 
scribed functionality may be the private and authenticated communi- 
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cation of information through the Internet, the holding of tamper-proof 
and secret electronic voting, or conducting any “fault-resilient” multi¬ 
party computation. Indeed, the scope of modern cryptography is very 
broad, and it stands in contrast to “classical” cryptography (which has 
focused on the single problem of enabling secret communication over 
insecure communication media). 

The design of cryptographic systems is a very difficult task. One 
cannot rely on intuitions regarding the “typical” state of the environ¬ 
ment in which the system operates. For sure, the adversary attacking the 
system will try to manipulate the environment into “untypical” states. 
Nor can one be content with counter-measures designed to withstand 
specific attacks, since the adversary (which acts after the design of the 
system is completed) will try to attack the schemes in ways that are 
different from the ones the designer had envisioned. The validity of the 
above assertions seems self-evident, but still some people hope that in 
practice ignoring these tautologies will not result in actual damage. 
Experience shows that these hopes rarely come true; cryptographic 
schemes based on make-believe are broken, typically sooner than later. 

In view of the foregoing, we believe that it makes little sense to make 
assumptions regarding the specific strategy that the adversary may use. 
The only assumptions that can be justified refer to the computational 
abilities of the adversary. Furthermore, the design of cryptographic sys¬ 
tems has to be based on firm foundations ; whereas ad-hoc approaches 
and heuristics are a very dangerous way to go. A heuristic may make 
sense when the designer has a very good idea regarding the environ¬ 
ment in which a scheme is to operate, yet a cryptographic scheme has 
to operate in a maliciously selected environment which typically tran¬ 
scends the designer’s view. 

This primer is aimed at presenting the foundations for cryptography. 
The foundations of cryptography are the paradigms, approaches and 
techniques used to conceptualize, define and provide solutions to nat¬ 
ural “security concerns”. We will present some of these paradigms, 
approaches and techniques as well as some of the fundamental results 
obtained using them. Our emphasis is on the clarification of funda¬ 
mental concepts and on demonstrating the feasibility of solving several 
central cryptographic problems. 
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Solving a cryptographic problem (or addressing a security concern) 
is a two-stage process consisting of a definitional stage and a construc¬ 
tional stage. First, in the definitional stage, the functionality underlying 
the natural concern is to be identified, and an adequate cryptographic 
problem has to be defined. Trying to list all undesired situations is 
infeasible and prone to error. Instead, one should define the function¬ 
ality in terms of operation in an imaginary ideal model, and require a 
candidate solution to emulate this operation in the real, clearly defined, 
model (which specifies the adversary’s abilities). Once the definitional 
stage is completed, one proceeds to construct a system that satisfies 
the definition. Such a construction may use some simpler tools, and its 
security is proved relying on the features of these tools. In practice, of 
course, such a scheme may need to satisfy also some specific efficiency 
requirements. 

This primer focuses on several archetypical cryptographic problems 
(e.g., encryption and signature schemes) and on several central tools 
(e.g., computational difficulty, pseudorandomness, and zero-knowledge 
proofs). For each of these problems (resp., tools), we start by presenting 
the natural concern underlying it (resp., its intuitive objective), then 
define the problem (resp., tool), and finally demonstrate that the prob¬ 
lem may be solved (resp., the tool can be constructed). In the latter 
step, our focus is on demonstrating the feasibility of solving the prob¬ 
lem, not on providing a practical solution. As a secondary concern, we 
typically discuss the level of practicality (or impracticality) of the given 
(or known) solution. 


Computational difficulty 

The aforementioned tools and applications (e.g., secure encryption) 
exist only if some sort of computational hardness exists. Specifically, 
all these problems and tools require (either explicitly or implicitly) the 
ability to generate instances of hard problems. Such ability is captured 
in the definition of one-way functions. Thus, one-way functions are the 
very minimum needed for doing most natural tasks of cryptography. (It 
turns out, as we shall see, that this necessary condition is “essentially” 
sufficient; that is, the existence of one-way functions (or augmentations 
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and extensions of this assumption) suffices for doing most of crypto¬ 
graphy.) 

Our current state of understanding of efficient computation does 
not aiiow us to prove that one-way functions exist. In particular, if 
V = MV then no one-way functions exist. Furthermore, the existence 
of one-way functions implies that MV is not contained in BVV D V 
(not even “on the average”). Thus, proving that one-way functions 
exist is not easier than proving that V 7 ^ MV\ in fact, the former task 
seems significantly harder than the latter. Hence, we have no choice (at 
this stage of history) but to assume that one-way functions exist. As 
justification to this assumption we may only offer the combined beliefs 
of hundreds (or thousands) of researchers. Furthermore, these beliefs 
concern a simply stated assumption, and their validity follows from 
several widely believed conjectures which are central to various fields 
(e.g., the conjectured intractability of integer factorization is central to 
computational number theory). 

Since we need assumptions anyhow, why not just assume what we 
want (i.e., the existence of a solution to some natural cryptographic 
problem)? Well, first we need to know what we want: as stated above, 
we must first clarify what exactly we want; that is, go through the 
typically complex definitional stage. But once this stage is completed, 
can we just assume that the definition derived can be met? Not really: 
once a definition is derived, how can we know that it can be met at 
all? The way to demonstrate that a definition is viable (and that the 
corresponding intuitive security concern can be satisfied at all) is to 
construct a solution based on a better understood assumption (i.e., 
one that is more common and widely believed). For example, look¬ 
ing at the definition of zero-knowledge proofs, it is not a-priori clear 
that such proofs exist at all (in a non-trivial sense). The non-triviality 
of the notion was first demonstrated by presenting a zero-knowledge 
proof system for statements, regarding Quadratic Residuosity, which 
are believed to be hard to verify (without extra information). Further¬ 
more, contrary to prior beliefs, it was later shown that the existence 
of one-way functions implies that any NP-statement can be proved in 
zero-knowledge. Thus, facts that were not known to hold at all (and 
even believed to be false), were shown to hold by reduction to widely 
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believed assumptions (without which most of modern cryptography col¬ 
lapses anyhow). To summarize, not all assumptions are equal, and so 
reducing a complex, new and doubtful assumption to a widely-believed 
simple (or even merely simpler) assumption is of great value. Further¬ 
more, reducing the solution of a new task to the assumed security of 
a well-known primitive typically means providing a construction that, 
using the known primitive, solves the new task. This means that we do 
not only know (or assume) that the new task is solvable but we also 
have a solution based on a primitive that, being well-known, typically 
has several candidate implementations. 


Prerequisites and structure 

Our aim is to present the basic concepts, techniques and results in 
cryptography. As stated above, our emphasis is on the clarification of 
fundamental concepts and the relationship among them. This is done 
in a way independent of the particularities of some popular number 
theoretic examples. These particular examples played a central role in 
the development of the field and still offer the most practical imple¬ 
mentations of all cryptographic primitives, but this does not mean 
that the presentation has to be linked to them. On the contrary, we 
believe that concepts are best clarified when presented at an abstract 
level, decoupled from specific implementations. Thus, the most relevant 
background for this primer is provided by basic knowledge of algorithms 
(including randomized ones), computability and elementary probability 
theory. 

The primer is organized in two main parts, which are preceded by 
preliminaries (regarding efficient and feasible computations). The two 
parts are Part I - Basic Tools and Part II - Basic Applications. The basic 
tools consist of computational difficulty (one-way functions), pseudo¬ 
randomness and zero-knowledge proofs. These basic tools are used for 
the basic applications, which in turn consist of Encryption Schemes, 
Signature Schemes, and General Cryptographic Protocols. 

In order to give some feeling of the flavor of the area, we have 
included in this primer a few proof sketches, which some readers may 
find too terse. We stress that following these proof sketches is not 
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1: Introduction and Preliminaries 
Part I: Basic Tools 

2: Computational Difficulty (One-Way Functions) 
3: Pseudorandomness 
4: Zero-Knowledge 
Part II: Basic Applications 
5: Encryption Schemes 

6 : Signature and Message Authentication Schemes 
7: General Cryptographic Protocols 


Fig. 1.1 Organization of this primer 


essential to understanding the rest of the material. In general, later 
sections may refer to definitions and results in prior sections, but not 
to the constructions and proofs that support these results. It may be 
even possible to understand later sections without reading any prior 
section, but we believe that the order we chose should be preferred 
because it proceeds from the simplest notions to the most complex 
ones. 


Suggestions for further reading 


This primer is a brief summary of the author’s two-volume work on 
the subject (1651:1671). Furthermore, Part I corresponds to (6a), whereas 
Part II corresponds to (j67l ). Needless to say, the reader is referred to 
these textbooks for further detail. 

Two of the topics reviewed by this primer are zero-knowledge proofs 
(which are probabilistic) and pseudorandom generators (and func¬ 
tions) . A wider perspective on probabilistic proof systems and pseudo¬ 
randomness is provided in (j62l , Sections 2-3). 

Current research on the foundations of cryptography appears in gen¬ 
eral computer science conferences (e.g., FOCS and STOC), in crypto¬ 
graphy conferences (e.g., Crypto and EuroCrypt) as well as in the newly 
established Theory of Cryptography Conference (TCC). 
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Practice. The aim of this primer is to introduce the reader to the 
theoretical foundations of cryptography. As argued above, such founda¬ 
tions are necessary for sound practice of cryptography. Indeed, practice 
requires more than theoretical foundations, whereas the current primer 
makes no attempt to provide anything beyond the latter. However, 
given a sound foundation, one can learn and evaluate various prac¬ 
tical suggestions that appear elsewhere (e.g., in (971')). On the other 
hand, lack of sound foundations results in inability to critically eval¬ 
uate practical suggestions, which in turn leads to unsound decisions. 
Nothing could be more harmful to the design of schemes that need to 
withstand adversarial attacks than misconceptions about such attacks. 


Non-cryptographic references: Some “non-cryptographic” works 
were referenced for sake of wider perspective. Examples include 0; B 


55; 


63; iza laaliia). 


1.2 Preliminaries 

Modern cryptography, as surveyed here, is concerned with the con¬ 
struction of efficient schemes for which it is infeasible to violate the 
security feature. Thus, we need a notion of efficient computations as 
well as a notion of infeasible ones. The computations of the legitimate 
users of the scheme ought be efficient, whereas violating the security 
features (by an adversary) ought to be infeasible. We stress that we do 
not identify feasible computations with efficient ones, but rather view 
the former notion as potentially more liberal. 


Efficient computations and infeasible ones 

Efficient computations are commonly modeled by computations that are 
polynomial-time in the security parameter. The polynomial bounding 
the running-time of the legitimate user’s strategy is fixed and typically 
explicit (and small). Indeed, our aim is to have a notion of efficiency 
that is as strict as possible (or, equivalently, develop strategies that are 
as efficient as possible). Here (i.e., when referring to the complexity 
of the legitimate users) we are in the same situation as in any algo¬ 
rithmic setting. Things are different when referring to our assumptions 
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regarding the computational resources of the adversary, where we refer 
to the notion of feasible that we wish to be as wide as possible. A com¬ 
mon approach is to postulate that feasible computations are polynomial¬ 
time too, but here the polynomial is not a-priori specified (and is to 
be thought of as arbitrarily large). In other words, the adversary is 
restricted to the class of polynomial-time computations and anything 
beyond this is considered to be infeasible. 

Although many definitions explicitly refer to the convention of asso¬ 
ciating feasible computations with polynomial-time ones, this conven¬ 
tion is inessential to any of the results known in the area. In all cases, 
a more general statement can be made by referring to a general notion 
of feasibility, which should be preserved under standard algorithmic 
composition, yielding theories that refer to adversaries of running-time 
bounded by any specific super-polynomial function (or class of func¬ 
tions) . Still, for sake of concreteness and clarity, we shall use the former 
convention in our formal definitions (but our motivational discussions 
will refer to an unspecified notion of feasibility that covers at least 
efficient computations). 


Randomized (or probabilistic) computations 

Randomized computations play a central role in cryptography. One 
fundamental reason for this fact is that randomness is essential for 
the existence (or rather the generation) of secrets. Thus, we must allow 
the legitimate users to employ randomized computations, and certainly 
(since randomization is feasible) we must consider also adversaries that 
employ randomized computations. This brings up the issue of success 
probability: typically, we require that legitimate users succeed (in ful¬ 
filling their legitimate goals) with probability 1 (or negligibly close to 
this), whereas adversaries succeed (in violating the security features) 
with negligible probability. Thus, the notion of a negligible probability 
plays an important role in our exposition. One requirement of the defi¬ 
nition of negligible probability is to provide a robust notion of rareness: 
A rare event should occur rarely even if we repeat the experiment for a 
feasible number of times. That is, in case we consider any polynomial¬ 
time computation to be feasible, a function is called negligible 
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if 1 — (1 — p(n)) p < 0.01 for every polynomial p and sufficiently big 
n (i.e., p is negligible if for every positive polynomial p' the function 
p(-) is upper-bounded by l/p'{-)). However, if we consider the function 
T(n) to provide our notion of infeasible computation then functions 
bounded above by 1/T(n) are considered negligible (in n). 

We will also refer to the notion of noticeable probability. Here the 
requirement is that events that occur with noticeable probability, will 
occur almost surely (i.e., except with negligible probability) if we repeat 
the experiment for a polynomial number of times. Thus, a function 
v : N —► N is called noticeable if for some positive polynomial p 1 the 
function i/(-) is lower-bounded by 1 /j/(•). 



Part I 

Basic Tools 


10 



11 


In this part we survey three basic tools used in modern cryptography. 
The most basic tool is computational difficulty, which in turn is cap¬ 
tured by the notion of one-way functions. Next, we survey the notion 
of computational indistinguishability, which underlies the theory of 
pseudorandomness as well as much of the rest of cryptography. In par¬ 
ticular, pseudorandom generators and functions are important tools 
that will be used in later sections. Finally, we survey zero-knowledge 
proofs, and their use in the design of cryptographic protocols. For more 
details regarding the contents of the current part, see our textbook (1651 ). 




2 


Computational Difficulty and One-way Functions 


Modern cryptography is concerned with the construction of systems 
that are easy to operate (properly) but hard to foil. Thus, a complexity 
gap (between the ease of proper usage and the difficulty of deviating 
from the prescribed functionality) lies at the heart of modern crypto¬ 
graphy. However, gaps as required for modern cryptography are not 
known to exist; they are only widely believed to exist. Indeed, almost 
all of modern cryptography rises or falls with the question of whether 
one-way functions exist. We mention that the existence of one-way 
functions implies that MV contains search problems that are hard to 
solve on the average , which in turn implies that MV is not contained 
in BTV (i.e., a worst-case complexity conjecture). 

Loosely speaking, one-way functions are functions that are easy to 
evaluate but hard (on the average) to invert. Such functions can be 
thought of as an efficient way of generating “puzzles” that are infeasible 
to solve (i.e., the puzzle is a random image of the function and a solution 
is a corresponding preimage). Furthermore, the person generating the 
puzzle knows a solution to it and can efficiently verify the validity of 
(possibly other) solutions to the puzzle. Thus, one-way functions have, 
by definition, a clear cryptographic flavor (i.e., they manifest a gap 
between the ease of one task and the difficulty of a related one). 


13 
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HARD 


Fig. 2.1 One-way functions - an illustration. 


2.1 One-way functions 

One-way functions are functions that are efficiently computable but 
infeasible to invert (in an average-case sense). That is, a function / : 
{0,1}* —► {0,1}* is called one-way if there is an efficient algorithm 
that on input x outputs f(x), whereas any feasible algorithm that tries 
to find a preimage of f{x) under / may succeed only with negligible 
probability (where the probability is taken uniformly over the choices 
of x and the algorithm’s coin tosses). Associating feasible computations 
with probabilistic polynomial-time algorithms, we obtain the following 
definition. 


Definition 2.1. (one-way functions): A function / : {0,1}* —► {0,1}* 
is called one-way if the following two conditions hold: 

(1) easy to evaluate: There exist a polynomial-time algorithm A 
such that A(x) = f(x) for every x 6 {0,1}*. 

(2) hard to invert: For every probabilistic polynomial-time algo¬ 
rithm A', every polynomial p, and all sufficiently large n, 

1 

p(n ) 


Pr [A'(f(x),l n )ef-\f(x))] < 
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where the probability is taken uniformly over all the possible 

_ choices of x E {0, l} n and all the possible outcomes of the 

A1 . internal coin tosses of algorithm A'. „ 

Algorithm A is given the auxiliary input 1 so to allow it to run m 

time polynomial in the length of x, which is important in case / drasti¬ 
cally shrinks its input (e.g., |/(x)| = 0(log|x|)). Typically, / is length 
preserving, in which case the auxiliary input l n is redundant. Note 
that A' is not required to output a specific preimage of /(x); any pre¬ 
image (i.e., element in the set / _ 1 (/(x))) will do. (Indeed, in case / is 
1 -1, the string x is the only preimage of /(x) under /; but in general 
there may be other preimages.) It is required that algorithm A! fails (to 
find a preimage) with overwhelming probability, when the probability 
is also taken over the input distribution. That is, / is “typically” hard 
to invert, not merely hard to invert in some (“rare”) cases. 

Some of the most popular candidates for one-way functions are 
based on the conjectured intractability of computational problems in 
number theory. One such conjecture is that it is infeasible to factor 
large integers. Consequently, the function that takes as input two (equal 
length) primes and outputs their product is widely believed to be a one¬ 
way function. Furthermore, factoring such a composite is infeasible if 
and only if squaring modulo such a composite is a one-way function 
(see ( lod )). For certain composites (i.e., products of two primes that 
are both congruent to 3 mod 4), the latter function induces a permuta¬ 
tion over the set of quadratic residues modulo this composite. A related 
permutation, which is widely believed to be one-way, is the RSA func¬ 
tion (H): x e-> x e mod N, where N = P ■ Q is a composite as above, e 
is relatively prime to (P — 1) • (Q — 1), and x E {0,..., N — 1}. The latter 
examples (as well as other popular suggestions) are better captured by 
the following formulation of a collection of one-way functions (which is 
indeed related to Definition 12.11) : 


Definition 2.2. (collections of one-way functions): A collection of 
functions, {/): Di —> {0, l}*} ig j, is called one-way if there exists three 
probabilistic polynomial-time algorithms, I, D and F. so that the fol¬ 
lowing two conditions hold: 
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(1) easy to sample and compute: On input 1”, the output of 
(the index selection) algorithm I is distributed over the set 
I 0 {0,l} n (i.e., is an n-bit long index of some function). 
On input (an index of a function) i £ I, the output of (the 
domain sampling) algorithm D is distributed over the set Di 
(i.e., over the domain of the function). On input i £ I and 
x £ Di, (the evaluation) algorithm F always outputs fi(x). 

(2) hard to For every probabilistic polynomial-time algo¬ 

rithm, A', every positive polynomial p(-), and all sufficiently 
large n’s 


Pr 


A l (i,f i {x))£f i 1 {fi{x)) 


1 

p{n) 


where i <— /(l n ) and x <— D{i). 


The collection is said to be a collection of permutations if each of the 
fi s is a permutation over the corresponding Di, and D{i) is almost 
uniformly distributed in Di. 


For example, in the case of the RSA, /jv, e : Dy e —> DN, e satisfies 
fN,e(%) = x e mod N, where Zbv, e = {0, ...,7V — 1}. Definition 12.21 is 
also a good starting point for the definition of a trapdoor permuta¬ 
tion n Loosely speaking, the latter is a collection of one-way permuta¬ 
tions augmented with an efficient algorithm that allows for inverting 
the permutation when given adequate auxiliary information (called a 
trapdoor). 


Definition 2.3. (trapdoor permutations): A collection of permutations 
as in Definition 12.2l is called a trapdoor permutation if there are two aux¬ 
iliary probabilistic polynomial-time algorithms I' and F -1 such that 
(1) the distribution I'{l n ) ranges over pairs of strings so that the first 

1 Note that this condition refers to the distributions /(l n ) and D(i), which are merely 
required to range over I D {0, l} n and Di, respectively. (Typically, the distributions /(l n ) 
and D(i) are (almost) uniform over I n {0, l} n and Di, respectively.) 

2 Indeed, a more adequate term would be a collection of trapdoor permutations, but the 
shorter (and less precise) term is the commonly used one. 
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string is distributed as in /(1"), and (2) for every (i,t) in the range of 
I'(l n ) and every x £ Di it holds that fi(x)) = x. (That is, t is a 

trapdoor that allows to invert /,;.) 


For example, in the case of the RSA, can be inverted by raising to 
the power d (modulo N = P Q ), where d is the multiplicative inverse of 
e modulo (P— 1)-(Q — 1). Indeed, in this case, the trapdoor information 
is (N, d). 

Strong versus weak one-way functions 

Recall that the above definitions require that any feasible algorithm 
succeeds in inverting the function with negligible probability. A weaker 
notion only requires that any feasible algorithm fails to invert the 
function with noticeable probability. It turns out that the existence of 
such weak one-way functions implies the existence of strong one-way 
functions (as defined above). The construction itself is straightforward: 
one just parses the argument to the new function into sufficiently many 
blocks, and applies the weak one-way function on the individual blocks. 
We warn that the hardness of inverting the resulting function is not 
established by mere “combinatorics” (i.e., considering the relative vol¬ 
ume of S* in U t , for S C U, where S represents the set of “easy to invert” 
images). Specifically, one may not assume that the potential inverting 
algorithm works independently on each block. Indeed this assumption 
seems reasonable, but we should not assume that the adversary behaves 
in a reasonable way (unless we can actually prove that it gains nothing 
by behaving in other ways, which seem unreasonable to us). 

The hardness of inverting the resulting function is proved via a 
so-called ‘deducibility argument” (which is used to prove all condi¬ 
tional results in the area). Specifically, we show that any algorithm that 
inverts the resulting function F with non-negligible success probability 
can be used to construct an algorithm that inverts the original function 
/ with success probability that violates the hypothesis (regarding /). In 
other words, we reduce the task of “strongly inverting” / (i.e., violating 
its weak one-wayness) to the task of “weakly inverting” F (i.e., violating 
its strong one-wayness). We hint that, on input y = f(x), the reduction 
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invokes the TMnverter (polynomially) many times, each time feeding it 
with a sequence of random /-images that contains y at a random loca¬ 
tion. (Indeed such a sequence corresponds to a random image of F.) 
The analysis of this reduction, presented in (65, Sec. 2.3), demonstrates 
that dealing with computational difficulty is much more involved than 
the analogous combinatorial question. An alternative demonstration of 
the difficulty of reasoning about computational difficulty (in compar¬ 
ison to an analogous purely probabilistic situation) is provided in the 
proof of Theorem 12.51 


2.2 Hard-core predicates 

Loosely speaking, saying that a function / is one-way implies that given 
y (in the range of /) it is infeasible to find a preimage of y under /. 
This does not mean that it is infeasible to find out partial informa¬ 
tion about the preimage(s) of y under /. Specifically it may be easy 
to retrieve half of the bits of the preimage (e.g., given a one-way func¬ 
tion / consider the function g defined by g(x,r) = f (f(x),r), for every 
|a:| = |r|). As will become clear in subsequent sections, hiding partial 
information (about the function’s preimage) plays an important role 
in more advanced constructs (e.g., secure encryption). Thus, we will 
first show how to transform any one-way function into a one-way func¬ 
tion that hides specific partial information about its preimage, where 
this partial information is easy to compute from the preimage itself. 
This partial information can be considered as a “hard core” of the dif¬ 
ficulty of inverting /. Loosely speaking, a polynomial-time computable 
(Boolean) predicate b, is called a hard-core of a function / if no feasible 
algorithm, given f(x), can guess b(x) with success probability that is 
non-negligibly better than one half. 


Definition 2.4. (hard-core predicates (3A)): A polynomial-time com¬ 
putable predicate b : {0,1}* —> {0,1} is called a hard-core of a function 
/ if for every probabilistic polynomial-time algorithm A', every positive 
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polynomial p(-), and all sufficiently large re’s 

Pr [A'(f(x)) = b(x)] <\ + ^ 

where the probability is taken uniformly over all the possible choices 
of x £ {0, l} n and all the possible outcomes of the internal coin tosses 
of algorithm A'. 

Note that for every b : {0,1}* —*■ {0,1} and / : {0,1}* —*■ {0,1}*, 
there exist obvious algorithms that guess b(x) from f(x ) with success 
probability at least one half (e.g., the algorithm that, obliviously of its 
input, outputs a uniformly chosen bit). Also, if b is a hard-core predicate 
(for any function) then it follows that b is almost unbiased (i.e., for a 
uniformly chosen x. the difference |Pr[6(x) = 0] — Pr[6(®) = l]| must be 
a negligible function in re). Finally, if b is a hard-core of a 1-1 function 
/ that is polynomial-time computable then / is a one-way function. 


Theorem 2.5. ( 1172) . see simpler proof in 16A Sec. 2.5.2)): For any 
one-way function /, the inner-product mod 2 of x and r is a hard-core 
of ?{x,r) = (f(x),r). 


The proof is by a so-called ‘deducibility argument” (which is used to 
prove all conditional results in the area). Specifically, we reduce the task 
of inverting / to the task of predicting the hard-core of f. while mak¬ 
ing sure that the reduction (when applied to input distributed as in the 
inverting task) generates a distribution as in the definition of the pre¬ 
dicting task. Thus, a contradiction to the claim that b is a hard-core of f 
yields a contradiction to the hypothesis that / is hard to invert. We stress 
that this argument is far more complex than analyzing the correspond¬ 
ing “probabilistic” situation (i.e., the distribution of the inner-product 
mod 2 of A and r, conditioned on a uniformly selected r £ {0, l} n , where 
A is a random variable with super-logarithmic min-entropy, which rep¬ 
resents the “effective” knowledge of x. when given /(®))Jf| 


3 The min-entropy of X is defined as min^{log 2 (l/Pr[X = u])}; tha t is, if X has min-entropy 
m then max^{Pr[X = u]} = 2 -m . The Leftover Hashing Lemma dl20l; [27l ;l87h implies that, 
in this case, Pr[6(X, U n ) = l|f^n] = ■|d=2 - ^( m ), where U n denotes the uniform distribution 
over {0, l} n , and b(u,v) denotes the inner-product mod 2 of u and v. 
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Proof sketch: The actual proof refers to an arbitrary algorithm B 
that, when given (/(x),r), tries to guess b(x,r). Suppose that this 
algorithm succeeds with probability ^+e, where the probability is taken 
over the random choices of x and r (as well as the internal coin tosses 
of B). By an averaging argument, we first identify a e/2 fraction of the 
possible coin tosses of B such that using any of these coin sequences B 
succeeds with probability at least ^ + e/2. Similarly, we can identify a 
e/4 fraction of the x’s such that B succeeds (in guessing b(x,r)) with 
probability at least | + e/4, where now the probability is taken only 
over the r’s. We will show how to use B in order to invert /, on input 
f(x), provided that x is in the good set (which has density e/4). 

As a warm-up, suppose for a moment that, for the aforemen¬ 
tioned x’s, algorithm B succeeds with probability p > | + l/poly(|x|) 
(rather than at least ^ + e/4). In this case, retrieving x from f(x) 
is quite easy: To retrieve the i th bit of x, denoted x*, we first ran¬ 
domly select r £ {0, and obtain B(f(x),r ) and B(f(x),r(B e l ), 
where e* = 0* 1 lO^I - * and v © u denotes the addition mod 2 of the 
binary vectors v and u. Note that if both B(f(x),r) = b(x,r) and 
B(f{x),r®e l ) = 6(x, r©e*) indeed hold, then B(f(x),r)®B(f(x),r®e l ) 
equals b(x,r) © b(x,r © e l ) = b(x,e l ) = x t . The probability that both 
B(f(x),r) = b(x, r) and B(f(x),r © e l ) = b(x,r © e*) hold, for a random 
r, is at least 1 — 2 • (1 — p) > ^ + ' ^ ence ’ repeating the above 

procedure sufficiently many times (using independent random choices 
of such r’s) and ruling by majority, we retrieve Xi with very high prob¬ 
ability. Similarly, we can retrieve all the bits of x, and hence invert / 
on f(x). However, the entire analysis was conducted under (the unjus¬ 
tifiable) assumption that p > f + poiy/u i ) > whereas we only know that 
P > l + f (for e > l/poly(|x|)). 

The problem with the above procedure is that it doubles the orig¬ 
inal error probability of algorithm B on inputs of the form (/(x),-). 
Under the unrealistic assumption (made above), that B’s average error 
on such inputs is non-negligibly smaller than the “error-doubling” 
phenomenon raises no problems. However, in general (and even in the 
special case where B’s error is exactly |) the above procedure is unlikely 
to invert /. Note that the average error probability of B (for a fixed 
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f(x), when the average is taken over a random r) cannot be decreased 
by repeating B several times (e.g., for every x, it may be that B always 
answer correctly on three quarters of the pairs (/(x), r), and always err 
on the remaining quarter). What is required is an alternative way of 
using the algorithm B, a way that does not double the original error 
probability of B. 

The key idea is to generate the r’s in a way that allows to apply 
algorithm B only once per each r (and *), instead of twice. Specifically, 
we will use algorithm B to obtain a “guess” for 6(x,r©e*), and obtain 
b{x,r ) in a different way (which does not use B ). The good news is 
that the error probability is no longer doubled, since we only use B to 
get a “guess” of b(x, r © e l ). The bad news is that we still need to know 
b(x,r), and it is not clear how we can know b(x,r ) without applying 
B. The answer is that we can guess b{x, r ) by ourselves. This is fine if 
we only need to guess b{x,r ) for one r (or logarithmically in |x| many 
r’s), but the problem is that we need to know (and hence guess) the 
value of 6(x, r ) for polynomially many r’s. The obvious way of guessing 
these b(x, r)’s yields an exponentially small success probability. Instead, 
we generate these polynomially many r’s such that, on one hand they 
are “sufficiently random” whereas, on the other hand, we can guess all 
the 6(x,r)’s with noticeable success probability!^] Specifically, generat¬ 
ing the r’s in a specific pairwise independent manner will satisfy both 
(seemingly contradictory) requirements. We stress that in case we are 
successful (in our guesses for all the fe(x,r)’s), we can retrieve x with 
high probability. Hence, we retrieve x with noticeable probability. 

A word about the way in which the pairwise independent r’s are gen¬ 
erated (and the corresponding 6(x,r)’s are guessed) is indeed in place. 
To generate m = poly(|x|) many r’s, we uniformly (and independently) 
select £ = f log 2 (m + 1) strings in {0,Let us denote these strings 
by s 1 ,...^ . We then guess ^(xjS 1 ) through b(x,s i ). Let us denote 
these guesses, which are uniformly (and independently) chosen in {0,1}, 
by a 1 through a 1 . Hence, the probability that all our guesses for the 
b(x, s*)’s are correct is = p 0 iy(| x .|) • The different r’s correspond to the 
different non-empty subsets of {1,2, Specifically, for every such 


4 Alternatively, we can try all polynomially many possible guesses. 
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subset J, we let r J = ©jgjs - 7 . The reader can easily verify that the r J ’s 
are pairwise independent and each is uniformly distributed in {0,1}I X L 
The key observation is that b(x,r J ) = b(x, ©jgjs- 7 ) = ®j^jb(x, s J ). 
Hence, our guess for b(x,r J ) is ©jgjcH, and with noticeable probabil¬ 
ity all our guesses are correct. □ 



3 


Pseudorandomness 


In practice “pseudorandom” sequences are often used instead of truly 
random sequences. The underlying belief is that if an (efficient) appli¬ 
cation performs well when using a truly random sequence then it will 
perform essentially as well when using a “pseudorandom” sequence. 
However, this belief is not supported by ad-hoc notions of “pseudoran¬ 
domness” such as passing the statistical tests in (92]) or having large 
linear-complexity (as in (1830). In contrast, the above belief is an easy 
corollary of defining pseudorandom distributions as ones that are com¬ 
putationally indistinguishable from uniform distributions. 

Loosely speaking, pseudorandom generators are efficient procedures 
for creating long “random-looking” sequences based on few truly ran¬ 
dom bits (i.e., a short random seed). The relevance of such constructs 
to cryptography is in the ability of legitimate users that share short 
random seeds to create large objects that look random to any feasible 
adversary (which does not know the said seed). 
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Pseudorandomness 


3.1 Computational indistinguishability 


Indistinguishable things are identical 
(or should be considered as identical). 

The Principle of Identity of Indiscernibles 
G.W. Leibniz (1646-1714) 

(Leibniz admits that counterexamples to this principle are conceivable, 
but will not occur in real life because God is much too benevolent.) 

A central notion in modern cryptography is that of “ef fecti ve sim¬ 
ilarity” (introduced by Goldwasser, Micali and Yao 0801 ; 123})). The 
underlying thesis is that we do not care whether or not objects are 
equal, all we care about is whether or not a difference between the 
objects can be observed by a feasible computation. In case the answer 
is negative, the two objects are equivalent as far as any practical appli¬ 
cation is concerned. Indeed, in the sequel we will often interchange 
such (computationally indistinguishable) objects. Let X = {Y n } ne ^ 
and Y = {Y n }neN be probability ensembles such that each X n and 
Y n is a distribution that ranges over strings of length n (or polyno¬ 
mial in n). We say that X and Y are computationally indistinguishable 
if for every feasible algorithm A the difference d,A(n) = f |Pr[A(A n ) = 
1] — Pr[A(l^) = l]| is a negligible function in n. That is: 


(computational indistinguishability (8C; 12,4) ): We 


Definition 3.1. 

say that X = {Y n } ne j!j and Y = {T„} ne jsj are computationally indistin¬ 
guishable if for every probabilistic polynomial-time algorithm D every 
polynomial p, and all sufficiently large n, 

1 


\Pr[D(X n ) = l]-Pr[D(Y n ) = l}\ < 


p(n) 


where the probabilities are taken over the relevant distribution (i.e., 
either X n or Y n ) and over the internal coin tosses of algorithm D. 


That is, we can think of D as somebody who wishes to distinguish two 
distributions (based on a sample given to it), and think of 1 as D’s 
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verdict that the sample was drawn according to the first distribution. 
Saying that the two distributions are computationally indistinguishable 
means that if ZD is a feasible procedure then its verdict is not really 
meaningful (because the verdict is almost as often 1 when the input is 
drawn from the first distribution as when the input is drawn from the 
second distribution). 


Indistinguishability by multiple samples 


We comment that, for “efficiently constructible” distributions, indis¬ 
tinguishability by a single sample (as defined above) implies indistin¬ 
guishability by multiple samples (see (6a, Sec. 3.2.3)). The proof of 
this fact provides a simple demonstration of a central proof technique, 
known as a hybrid argument, which we briefly present next. 

To prove that a sequence of independently drawn samples of one dis¬ 
tribution is indistinguishable from a sequence of independently drawn 
samples from the other distribution, we consider hybrid sequences such 
that the hybrid consists of i samples taken from the first distribution 
and the rest taken from the second distribution. The “homogeneous” 
sequences (which we wish to prove to be computational indistinguish¬ 
able) are the extreme hybrids (i.e., the first and last hybrids consid¬ 
ered above). The key observation is that distinguishing the extreme 
hybrids (towards the contradiction hypothesis) yields a procedure for 
distinguishing single samples of the two distributions (contradicting the 
hypothesis that the two distributions are indistinguishable by a single 
sample). Specifically, if D distinguishes the extreme hybrids, then it 
also distinguishes a random pair of neighboring hybrids (i.e., D distin¬ 
guishes the z th hybrid from the i + 1 st hybrid, for a randomly selected 
i). Using D , we obtain a distinguisher D' of single samples: Given a 
single sample, D' selects i at random, generates i samples from the 
first distribution and the rest from the second, and invokes D with 
the corresponding sequence, while placing the input sample in location 
i+ 1 of the sequence. We stress that although the original distinguisher 
D (arising from the contradiction hypothesis) was only “supposed to 
work” for the extreme hybrids, we can consider ZTs performance on 
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any distribution that we please, and draw adequate conclusions (as we 
have done). 


seed 


Gen 


-[ 


output sequence 


a truly random sequence 


? 


Fig. 3.1 Pseudorandom generators - an illustration. 


3.2 Pseudorandom generators 

Loosely speaking, a pseudorandom generator is an efficient (determinis¬ 
tic) algorithm that on input of a short random seed outputs a (typically 
much) longer sequence that is computationally indistinguishable from a 
uniformly chosen sequence. Pseudorandom generators were introduced 
by Blum, Micali and Yao (J31; 123|), and are formally defined as follows. 


Definition 3.2. (pseudorandom generator Fit 1 12,4) ): Let £ : N —► N 
satisfy £{n) > n, for all n G N. A pseudorandom generator, with stretch 
function £, is a (deterministic) polynomial-time algorithm G satisfying 
the following: 


(1) For every s G {0,1}*, it holds that |G(s)| = £(|s|). 

(2) {G(U n )} ne ^ and {U^ n )} n£ ^ are computationally indistin¬ 
guishable, where U m denotes the uniform distribution over 

Indeed, the probability ensemble {G(U n )} n ^ is called pseudorandom. 


Thus, pseudorandom sequences can replace truly random sequences 
not only in “standard” algorithmic applications but also in crypto¬ 
graphic ones. That is, any cryptographic application that is secure 
when the legitimate parties use truly random sequences, is also secure 
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when the legitimate parties use pseudorandom sequences. The benefit 
in such a substitution (of random sequences by pseudorandom ones) is 
that the latter sequences can be efficiently generated using much less 
true randomness. Furthermore, in an interactive setting , it is possible 
to eliminate all random steps from the on-line execution of a program, 
by replacing them with the generation of pseudorandom bits based on 
a random seed selected and fixed off-line (or at set-up time). 

Various cryptographic applications of pseudorandom generators will 
be presented in the sequel, but first let us show a construction of 
pseudorandom generators based on the simpler notion of a one-way 
function. Using Theorem 12.51 we may actually assume that such a func¬ 
tion is accompanied by a hard-core predicate. We start with a simple 
construction that suffices for the case of 1-1 (and length-preserving) 
functions. 


Theorem 3.3. ((31; 12i\ ). see i bvl Sec. 3-4)): Let / be a 1-1 function 
that is length-preserving and efficiently computable, and b be a hard¬ 
core predicate of /. Then G(s) = b(s ) • b(f(s)) ■ ■ • &(/^N) -1 (s)) is a 
pseudorandom generator (with stretch function £), where f l+1 (x) = f 
and f°(x) c = x. 


As a concrete example, consider the permutatiorfl x >—> x 1 2 mod N, 
where N is the product of two primes each congruent to 3 (mod 4), 
and x is a quadratic residue modulo N. Then, we have Gjy(s) = 
lsb(s) • lsb(s 2 mod N) ■ ■ ■ lsb(s 2i(|s|) 1 mod N ), where lsb(x) is the least 
significant bit of x (which is a hard-core of the modular squaring func¬ 
tion |1)). 


Proof sketch of Theorem 13.31 We use the fundamental fact that 
asserts that the following two conditions are equivalent: 


1 It is a well-known fact (cf., JgBL Apdx. A.2.4)) that, for such N’ s, the mapping x 

x 2 mod AT is a permutation over the set of quadratic residues modulo N. 
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(1) The distribution X (in our case {G(U n )} n£ ^) is pseudoran¬ 
dom (i.e., is computationally indistinguishable from a uni¬ 
form distribution (on {bWjIneN))- 

(2) The distribution X is unpredictable in polynomial-time; that 
is, no feasible algorithm, given a prefix of the sequence, can 
guess its next bit with a non-negligible advantage over 

Clearly, pseudorandomness implies polynomial-time unpredictabil¬ 
ity (i.e., polynomial-time predictability violates pseudorandomness). 
The converse is shown using a hybrid argument, which refers to 
hybrids consisting of a prefix of X followed by truly random bits 
(i.e., a suffix of the uniform distribution). Thus, we focus on prov¬ 
ing that G'(U n ) is polynomial-time unpredictable, where G'(s ) = 
6(/^d s l) -1 (s)) • • • b(f(s )) • b(s) is the reverse of G(s). 

Suppose towards the contradiction that, for some j < £ = f £(n), 
given the j-bit long prefix of G'(U n ) an algorithm A' can predict the 
j + 1 st bit of G'(U n ). That is, given b(f e ^ 1 (s)) ■ ■ ■ 6(/ £_J (s)), algo¬ 
rithm A' predicts b(f^^ +1 \s)), where s is uniformly distributed in 
{0, l} n . Then, for x uniformly distributed in {0,l} n , given y = f(x) 
one can predict b(x) by invoking A' on input b(f 3 ~ 1 (y)) ■ ■ ■ b(y) = 
b{f 3 (x)) ■ ■ ■ b(f(x)), which in turn is polynomial-time computable from 
y = f(x). In the analysis, we use the hypothesis that / induces a per¬ 
mutation over {0,l} n , and associate x with □ 

We mention that the existence of a pseudorandom generator with 
any stretch function (including the very minimal stretch function 
£{n) = n + 1) implies the existence of pseudorandom generators 
for any desired stretch function. The construction is similar to the 
one presented in Theorem 13.31 That is, for a pseudorandom gener¬ 
ator G i, let F(x) (resp., B(x)) denote the first \x\ bits of G\{x) 
(resp., the |x| + 1 st bit of Gi(x)), and consider G(s) = B(s ) • 
B(F(s)) ■ ■ ■ B(F^'>~ 1 (s)), where i is the desired stretch. Although F is 
not necessarily 1-1, it can be shown that G is a pseudorandom generator 
@, Sec. 3.3.2). 

We conclude this section by mentioning that pseudorandom gen¬ 
erators can be constructed from any one-way function (rather than 
merely from one-way permutations, as above). On the other hand, the 
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existence of one-way functions is a necessary condition to the existence 
of pseudorandom generators. That is: 


Theorem 3.4. /1 8a): Pseudorandom generators exist if and only if one¬ 
way functions exist. 


The necessary condition is easy to establish. Given a pseudorandom 
generator G that stretches by a factor of two, consider the func¬ 
tion f(x) = G(x ) (or, to obtain a length preserving-function, let 
f{x,y ) = G(x), where \x\ = |y|). An algorithm that inverts / with 
non-negligible success probability (on the distribution f(U n ) = G(U n )) 
yields a distinguisher of {G(U n )} ne ^ from {L^njrieN; because the prob¬ 
ability that U r 2 n is an image of / is negligible. 


3.3 Pseudorandom functions 


Pseudorandom generators provide a way to efficiently generate long 
pseudorandom sequences from short random seeds. Pseudorandom 
functions, introduced and constructed by Goldreich, Goldwasser and 
Micali (68), are even more powerful: they provide efficient direct access 
to bits of a huge pseudorandom sequence (which is not feasible to 
scan bit-by-bit). More precisely, a pseudorandom function is an efficient 
(deterministic) algorithm that given an ra-bit seed , s, and an n-bit argu¬ 
ment, x, returns an n-bit string, denoted f s (x), so that it is infeasible 
to distinguish the values of f s , for a uniformly chosen s G {0, l} n , from 
the values of a truly random function F : {0, l} n —> {0,l} n . That is, 
the (feasible) testing procedure is given oracle access to the function 
(but not its explicit description), and cannot distinguish the case it is 
given oracle access to a pseudorandom function from the case it is given 
oracle access to a truly random function. 

One key feature of the above definition is that pseudorandom func¬ 
tions can be generated and shared by merely generating and sharing 
their seed; that is, a “random looking” function f s : {0, l} n — {0, l} n , 
is determined by its n-bit seed s. Parties wishing to share a “random 
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looking” function f s (determining 2 n -many values), merely need to gen¬ 
erate and share among themselves the n-bit seed s. (For example, one 
party may randomly select the seed s, and communicate it, via a secure 
channel, to all other parties.) Sharing a pseudorandom function allows 
parties to determine (by themselves and without any further commu¬ 
nication) random-looking values depending on their current views of 
the environment (which need not be known a priori). To appreciate the 
potential of this tool, one should realize that sharing a pseudorandom 
function is essentially as good as being able to agree, on the fly, on the 
association of random values to (on-line) given values, where the latter 
are taken from a huge set of possible values. We stress that this agree¬ 
ment is achieved without communication and synchronization: When¬ 
ever some party needs to associate a random value to a given value, 
v E {0, l} n , it will associate to v the (same) random value r v E {0, l} n 
(by setting r v = f s (v), where f s is a pseudorandom function agreed 
upon beforehand). 


Theorem 3.5. ($£&), see wft . Sec. 3.6.2)): Pseudorandom functions 
can be constructed using any pseudorandom generator. 


Proof sketch: Let G be a pseudorandom generator that stretches its 
seed by a factor of two (i.e., £(n) = 2n), and let Gq(s) (resp., G'i(s)) 
denote the first (resp., last) |s| bits in G(s). Define 

G<T lsr .a2<n( s ) = f G> |s| (’ ‘ ' Ga 2 (G ai (s)) ■ ■ •). 

We consider the function ensemble {/ s : {0,1}I S I — {0, l}^} s e{o,i}*) 

where f s (x) = f G x (s). Pictorially, the function f s is defined by n-step 
walks down a full binary tree of depth n having labels at the vertices. 
The root of the tree, hereafter referred to as the level 0 vertex of the 
tree, is labeled by the string s. If an internal vertex is labeled r then 
its left child is labeled G'o(r) whereas its right child is labeled G'i(r). 
The value of / s (x) is the string residing in the leaf reachable from the 
root by a path corresponding to the string x. 

We claim that the function ensemble {/s} s e{o,i}*i defined above, is 
pseudorandom. The proof uses the hybrid technique: The I th hybrid, 
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H^. is a function ensemble consisting of 2 2 *' n functions {0, l} n —* 
{0,l} n , each defined by 2* random n-bit strings, denoted s = 
( s /3)/3e{o,i} i - The value of such function hj at x = a(3, where \/3\ = i, is 
G a (sp). (Pictorially, the function hj is defined by placing the strings in 
s in the corresponding vertices of level i. and labeling vertices of lower 
levels using the very rule used in the definition of f s .) The extreme 
hybrids correspond to our indistinguishability claim (i.e., = fu n 

and H™ is a truly random function), and neighboring hybrids can be 
related to our indistinguishability hypothesis (specifically, to the indis¬ 
tinguishability of G(U n ) and Um under multiple samples). □ 

Useful variants (and generalizations) of the notion of pseudorandom 
functions include Boolean pseudorandom functions that are defined for 
all strings (i.e., f s : {0,1}* —► {0,1}) and pseudorandom functions 
that are defined for other domains and ranges (i.e., f s : {0, l} rf d s l) —> 
{ 0 ,l} r (M), f or arbitrary polynomially bounded functions d, r : N —> 
N). Various transformations between these variants are known (cf. (65, 
Sec. 3.6.4) and (67, Apdx. C.2)). 


Applications and a generic methodology. Pseudorandom func¬ 
tions are a very useful cryptographic tool: One may first design a 
cryptographic scheme assuming that the legitimate users have black¬ 
box access to a random function, and next implement the random func¬ 
tion using a pseudorandom function. The usefulness of this tool stems 
from the fact that having (black-box) access to a random function gives 
the legitimate parties a potential advantage over the adversary (which 
does not have free access to this function) o The security of the resulting 
implementation (which uses a pseudorandom function) is established 
in two steps: First one proves the security of an idealized scheme that 
uses a truly random function, and next one argues that the actual 
implementation (which uses a pseudorandom function) is secure (as 
otherwise one obtains an efficient oracle machine that distinguishes a 
pseudorandom function from a truly random one). 

2 The aforementioned methodology is sound provided that the adversary does not get the 
description of the pseudorandom function (i.e., the seed) in use, but has only (possibly 
limited) oracle access to it. This is different from the so-called Random Oracle Methodology 
formulated in ( 12^ ) and criticized in (|38h . 
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Zero-Knowledge 


Zero-knowledge proofs, introduced by Goldwasser, Micali and Rack- 
off (|8ll), provide a powerful tool for the design of cryptographic pro¬ 
tocols. Loosely speaking, zero-knowledge proofs are proofs that yield 
nothing beyond the validity of the assertion. That is, a verifier obtain¬ 
ing such a proof only gains conviction in the validity of the assertion 
(as if it was told by a trusted party that the assertion holds). This is 
formulated by saying that anything that is feasibly computable from 
a zero-knowledge proof is also feasibly computable from the (valid) 
assertion itself. The latter formulation follows the simulation paradigm, 
which is discussed next. 


4.1 The simulation paradigm 

A key question regarding the modeling of security concerns is how 
to express the intuitive requirement that an adversary “gains nothing 
substantial” by deviating from the prescribed behavior of an honest 
user. Our approach is that the adversary gains nothing if whatever it 
can obtain by unrestricted adversarial behavior can also be obtained 
within essentially the same computational effort by a benign behav- 
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Fig. 4.1 Zero-knowledge proofs — an illustration. 


ior. The definition of the “benign behavior” captures what we want 
to achieve in terms of security, and is specific to the security concern 
to be addressed. For example, in the previous paragraph, we said that 
a proof is zero-knowledge if it yields nothing (to the adversarial veri¬ 
fier) beyond the validity of the assertion (i.e., the benign behavior is any 
computation that is based (only) on the assertion itself, while assuming 
that the latter is valid). Other examples are discussed in Sections 15.11 
and 17.11 

A notable property of the aforementioned simulation paradigm, as 
well as of the entire approach surveyed here, is that this approach is 
overly liberal with respect to its view of the abilities of the adversary 
as well as to what might constitute a gain for the adversary. Thus, 
the approach may be considered overly cautious, because it prohibits 
also “non-harmful” gains of some “far-fetched” adversaries. We warn 
against this impression. Firstly, there is nothing more dangerous in 
cryptography than to consider “reasonable” adversaries (a notion which 
is almost a contradiction in terms): typically, the adversaries will try 
exactly what the system designer has discarded as “far-fetched”. Sec¬ 
ondly, it seems impossible to come up with definitions of security that 
distinguish “breaking the scheme in a harmful way” from “breaking it in 
a non-harmful way”: what is harmful is application-dependent, whereas 
a good definition of security ought to be application-independent (as 
otherwise using the scheme in any new application will require a full 
re-evaluation of its security). Furthermore, even with respect to a spe- 
















4.2. The actual definition 35 


cific application, it is typically very hard to classify the set of “harmful 
breakings”. 


4.2 The actual definition 


A proof is whatever convinces me. 


Shimon Even (1935-2004) 


Before defining zero-knowledge proofs, we have to define proofs. The 
standard notion of a static (i.e., non-inter active) proof will not do, 
because static zero-knowledge proofs exist only for sets that are easy 
to decide (i.e, are in BVV) (1761). whereas we are interested in zero- 
knowledge proofs for arbitrary NP-sets. Instead, we use the notion of 
an interactive proof (introduced exactly for that reason in (|8ll )). That 
is, here a proof is a (multi-round) randomized protocol for two parties, 
called verifier and prover, in which the prover wishes to convince the 
verifier of the validity of a given assertion. Such an interactive proof 
should allow the prover to convince the verifier of the validity of any 
true assertion (i.e., completeness), whereas NO prover strategy may fool 
the verifier to accept false assertions (i.e., soundness). Both the com¬ 
pleteness and soundness conditions should hold with high probability 
(i.e., a negligible error probability is allowed). The prescribed verifier 
strategy is required to be efficient. No such requirement is made with 
respect to the prover strategy; yet we will be interested in “relatively 
efficient” prover strategies (see below) 0 


1 We stress that the relative efficiency of the prover strategy refers to the strategy employed 
in order to prove valid assertions; that is, relative efficiency of the prover strategy is a 
strengthening of the completeness condition (which is indeed required for cryptographic 
applications). This should not be confused with the relaxation (i.e., weakening) of the 
soundness condition that restricts its scope to feasible adversarial prover strategies (rather 
than to all possible prover strategies). The resulting notion of “computational soundness” 
is discussed in Section 14.4.11 and indeed suffices in most cryptographic applications. Still, 
we believe that it is simpler to present the material in terms of interactive proofs (rather 
than in terms of computationally sound proofs). 






36 Zero-Knowledge 

Zero-knowledge is a property of some prover strategies. More gen¬ 
erally, we consider interactive machines that yield no knowledge while 
interacting with an arbitrary feasible adversary on a common input 
taken from a predetermined set (in our case the set of valid assertions). 
A strategy A is zero-knowledge on (inputs from) the set S if, for every 
feasible strategy B*, there exists a feasible computation C* such that 
two probability ensembles are computationally indistin- 

(1) {(A,!?*)^)}^ d =! f the output of B* after interacting with 

A on common input and 

(2) {C'*(x )} x£ 5 the output of C* on input x G S. 


the following 
guishabl^]: 


We stress that the first ensemble represents an actual execution of 
an interactive protocol, whereas the second ensemble represents the 
computation of a stand-alone procedure (called the “simulator”), which 
does not interact with anybody. 

The above definition does not account for auxiliary information that 
an adversary B* may have prior to entering the interaction. Account¬ 
ing for such auxiliary information is essential for using zero-knowledge 
proofs as subprotocols inside larger protocols (see (1711 ; 176111. This is 
taken care of by a stricter notion called auxiliary-input zero-knowledge. 


Definition 4.1. (zero-knowledge (81), revisited S3)) : A strategy A is 
auxiliary-input zero-knowledge on inputs from S if, for every probabilistic 


2 Here we refer to a natural extension of Definition 13.1 1 Rather than referring to ensembles 
indexed by N, we refer to ensembles indexed by a set S C {0,1}*. Typically, for an ensem¬ 
ble {Z a }a.eS 5 it holds that Z a ranges over strings of length that is polynomially-related 
to the length of a. We say that {V Q } ae 5 and {Va} a g 5 are computationally indistinguish¬ 
able if for every probabilistic polynomial-time algorithm D every polynomial p, and all 
sufficiently long qG5, 


\Pr[D(a,X a )=l]-Pr[D{ a ,Y ct ) = l}\ < -±- 

p(M) 


where the probabilities are taken over the relevant distribution (i.e., either X a or Yh) and 
over the internal coin tosses of algorithm D. 
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polynomial-time strategy B* and every polynomial p, there exists a 
probabilistic polynomial-time algorithm C* such that the following two 
probability ensembles are computationally indistinguishable: 

(1) {(A£*(z))(xO}a;eS,ze{oa}p(M) '= the output of B* when 
having auxiliary-input z and interacting with A on common 
input x G S'; and 

(2) {C*(x, z)} lG s jJKe {o i: L}p(M) ( = the output of C* on inputs x € 

S and z G {0, 


Almost all known zero-knowledge proofs are in fact auxiliary-input 
zero-knowledge. As hinted above, auxiliary-input zero-knowledge is pre¬ 
served under sequential composition (76). A simulator for the multiple- 
session protocol can be constructed by iteratively invoking the single¬ 
session simulator that refers to the residual strategy of the adversarial 
verifier in the given session (while feeding this simulator with the tran¬ 
script of previous sessions). Indeed, the residual single-session verifier 
gets the transcript of the previous sessions as part of its auxiliary input 
(i.e., 2 in Definition 14. 1|) . (For details, see (65, Sec. 4.3.4).) 


4.3 Zero-knowledge proofs for all NP-assertions and their 
applications 

A question avoided so far is whether zero-knowledge proofs exist at 
all. Clearly, every set in V (or rather in BVV) has a “trivial” zero- 
knowledge proof (in which the verifier determines membership by 
itself); however, what we seek is zero-knowledge proofs for statements 
that the verifier cannot decide by itself. 

Assuming the existence of “commitment schemes” (see below), 
which in turn exist if one-way functions exist f 101 : js^), there exist 
(auxiliary-input) zero-knowledge proofs of membership in any NP-set 
(i.e., sets having efficiently verifiable static proofs of membership). 
These zero-knowledge proofs, first constructed by Goldreich, Micali and 
Wigderson (75) (and depicted in Figure [472]) , have the following impor¬ 
tant property: the prescribed prover strategy is efficient, provided it is 
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given as auxiliary-input an NP-witness to the assertion (to be proved) 
That is: 


Theorem 4.2. ( (7 5), using 1 85: 10 A )): If one-way functions exist then 
every set S £ A fV has a zero-knowledge interactive proof. Furthermore, 
the prescribed prover strategy can be implemented in probabilistic 
polynomial-time, provided it is given as auxiliary-input an NP-witness 
for membership of the common input in S. 


Theorem 14. 2 1 makes zero-knowledge a very powerful tool in the design of 
cryptographic schemes and protocols (see below). We comment that the 


intractability assumption used in T heorem 14 .2 1 seems essential; see (|105 


1221 ). 


Analyzing the protocol of Figure 14.21 Let us consider a sin¬ 
gle execution of the main loop (and rely on the preservation of 
zero-knowledge under sequential composition). Clearly, the prescribed 
prover is implemented in probabilistic polynomial-time, and always 
convinces the verifier (provided that it is given a valid 3-coloring of 
the common input graph). In case the graph is not 3-colorable then, no 
matter how the prover behaves, the verifier will reject with probability 
at least 1/\E\ (because at least one of the edges must be improperly col¬ 
ored by the prover). We stress that the verifier selects uniformly which 
edge to inspect after the prover has committed to the colors of all ver¬ 
tices. Thus, Figure 14.21 depicts an interactive proof system for Graph 
3-Colorability (with error probability exp(— t)). As the reader might 
have guessed, the zero-knowledge property is the hardest to establish, 


3 The auxiliary-input given to the prescribed prover (in order to allow for an efficient imple¬ 
mentation of its strategy) is not to be confused with the auxiliary-input that is given to 
malicious verifiers (in the definition of auxiliary-input zero-knowledge). The former is typ¬ 
ically an NP-witness for the common input, which is available to the user that invokes the 
prover strategy (cf. the generic application discussed below). In contrast, the auxiliary- 
input that is given to malicious verifiers models arbitrary partial information that may be 
available to the adversary. 
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Commitment schemes are digital analogs of sealed envelopes (or, better, locked boxes). 
Sending a commitment means sending a string that binds the sender to a unique value 
without revealing this value to the receiver (as when getting a locked box). Decommitting 
to the value means sending some auxiliary information that allows the receiver to read 
the uniquely committed value (as when sending the key to the lock). 

def 

Common Input: A graph G(V,E). Suppose that V = {1, ...,n} for n = \V\. 
Auxiliary Input (to the prover): A 3-coloring ^6 : V —> {1,2,3}. 

The following 4 steps are repeated t ■ \E\ many times so to obtain soundness error 
exp(— t). 

Prover’s first step (PI): Select uniformly a permutation n over {1,2,3}. For 2 = 1 
to n, send the verifier a commitment to the value 7r((j)(i)). 

Verifier’s first step (VI): Select uniformly an edge e E E and send it to the prover. 
Prover’s second step (P2): Upon receiving e = (i,j) G E , decommit to the 2 -th and 
j -th values sent in Step (PI). 

Verifier’s second step (V2): Check whether or not the decommitted values are dif¬ 
ferent elements of {1,2,3} and whether or not they match the commitments 
received in Step (PI). 


Fig. 4.2 The zero-knowledge proof of Graph 3-Color ability (of ©)• Zero-knowledge proofs 
for other NP-sets can be obtained using the standard reductions. 


and we will confine ourselves to presenting an adequate simulator. We 
start with three simplifying conventions (which are useful in general): 

(1) Without loss of generality, we may assume that the cheat¬ 
ing verifier strategy is implemented by a deterministic 
polynomial-time algorithm with an auxiliary input. This is 
justified by fixing any outcome of the verifier’s coins (as part 
of the auxiliary input), and observing that our (uniform) 
simulation of the various (residual) deterministic strategies 
yields a simulation of the original probabilistic strategy. 

(2) Without loss of generality, it suffices to consider cheating 
verifiers that (only) output their view of the interaction (i.e., 
their input, coin tosses, and the messages they received). In 
other words, it suffices to simulate the view of the cheat¬ 
ing verifier rather than its output (which is the result of a 
polynomial-time post-processing of the view). 

(3) Without loss of generality, it suffices to construct a “weak 
simulator” that produces an output with some noticeable 
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probability, provided that (conditioned on producing out¬ 
put) the output is computationally indistinguishable from 
the desired distribution (i.e., the view of the cheating verifier 
in a real interaction). This is the case because, by repeatedly 
invoking this weak simulator (polynomially) many times, we 
may obtain a simulator that fails to produce an output with 
negligible probability. Finally, letting the simulator produce 
an arbitrary output rather than failing, we obtain a simulator 
that never fails (as required by the definition), while skewing 
the output distribution by at most a negligible amount. 


Our simulator starts by selecting uniformly and independently a ran¬ 
dom color (i.e., element of {1,2,3}) for each vertex, and feeding the 
verifier strategy with random commitments to these random colors. 
Indeed, the simulator feeds the verifier with a distribution that is very 
different from the distribution that the verifier sees in a real interaction 
with the prover. However, being computationally-restricted the verifier 
cannot tell these distributions apart (or else we obtain a contradiction 
to the security of the commitment scheme in use). Now, if the verifier 
asks to inspect an edge that is properly colored then the simulator per¬ 
forms the proper decommitment action and outputs the transcript of 
this interaction. Otherwise, the simulator halts proclaiming failure. We 
claim that failure occurs with probability approximately 1/3 (or else 
we obtain a contradiction to the security of the commitment scheme 
in use). Furthermore, based on the same hypothesis (but via a more 
complex proof (cf. (65, Sec. 4.4.2.3))), conditioned on not failing, the 
output of the simulator is computationally indistinguishable from the 
verifier’s view of the real interaction. 


Commitment schemes. Loosely speaking, commitment schemes 
are two-stage (two-party) protocols allowing for one party to commit 
itself (at the first stage) to a value while keeping the value secret. In 
a (second) latter stage, the commitment is “opened” and it is guaran¬ 
teed that the “opening” can yield only a single value determined in the 
committing phase. Thus, the (first stage of the) commitment scheme 
is both binding and hiding. A simple (uni-directional communication) 
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commitment scheme can be constructed based on any one-way 1-1 func¬ 
tion / (with a corresponding hard-core b ). To commit to a bit cr, the 
sender uniformly selects s G {0, l} n , and sends the pair (f(s), b(s ) ® cr). 
Note that this is both binding and hiding. An alternative construction, 
which can be based on any one-way function, uses a pseudorandom gen¬ 
erator G that stretches its seed by a factor of three (cf. Theorem 13.41) . 
A commitment is established, via two-way communication, as follows 
(cf. (JlOl)): The receiver selects uniformly r G {0,l} 3n and sends it to 
the sender, which selects uniformly s G {0, l} n and sends r © G(s) if 
it wishes to commit to the value one and G(s) if it wishes to commit 
to zero. To see that this is binding, observe that there are at most 2 2n 
“bad” values r that satisfy G'(so) = r®G(si) for some pair (sq, si), and 
with overwhelmingly high probability the receiver will not pick one of 
these bad values. The hiding property follows by the pseudorandomness 
of G. 


Zero-knowledge proofs for other NP-sets. By using the stan¬ 
dard Karp-reductions to 3-Colorability, the protocol of Figure 14.21 can 
be used for constructing zero-knowledge proofs for any set in MV. We 
comment that this is probably the first time that an NP-completeness 
result was used in a “positive” way (i.e., in order to construct something 
rather than in order to derive a hardness result) 0 


Efficiency considerations. The protocol in Figure 14.21 calls for 
invoking some constant-round protocol for a non-constant number of 
times (and its analysis relies on the preservation of zero-knowledge 
under sequential composition). At first glance, it seems that one can 
derive a constant-round zero-knowledge proof system (of negligible 
soundness error) by performing these invocations in parallel (rather 
than sequentially). Unfortunately, as indicated in (71), it is not clear 
that the resulting interactive proof is zero-knowledge. Still, under stan¬ 
dard intractability assumptions (e.g., the intractability of factoring), 
constant-round zero-knowledge proofs (of negligible soundness error) 


4 Subsequent positi ve u ses of completeness results have appeared in the context of inter¬ 
active proofs (|9 5 IllSt) , probabilistically checkable proofs (1 5 [ 5 5 I ; 0) , “hardness versus 

randomness trade-offs” ((7|), and statistical zero-knowledge (11158) . 
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do exist for every set in AfV (cf. (7Jj)). We comment that the number 
of rounds in a protocol is commonly considered the most important 
efficiency criterion (or complexity measure), and typically one desires 
to have it be a constant. 


A generic application. As mentioned above, Theorem 14.21 makes 
zero-knowledge a very powerful tool in the design of cryptographic 
schemes and protocols. This wide applicability is due to two important 
aspects regarding Theorem 14.21 Firstly, Theorem 14.21 provides a zero- 
knowledge proof for every NP-set, and secondly the prescribed prover 
can be implemented in probabilistic polynomial-time when given an 
adequate NP-witness. We now turn to a typical application of zero- 
knowledge proofs. In a typical cryptographic setting, a user U has a 
secret and is supposed to take some action depending on its secret. The 
question is how can other users verify that U indeed took the correct 
action (as determined by C/’s secret and publicly known information). 
Indeed, if U discloses its secret then anybody can verify that U took 
the correct action. However, U does not want to reveal its secret. Using 
zero-knowledge proofs we can satisfy both conflicting requirements (i.e., 
having other users verify that U took the correct action without vio¬ 
lating C/’s interest in not revealing its secret). That is, U can prove 
in zero-knowledge that it took the correct action. Note that C/’s claim 
to having taken the correct action is an NP-assertion (since C/’s legal 
action is determined as a polynomial-time function of its secret and 
the public information), and that U has an NP-witness to its valid¬ 
ity (i.e., the secret is an NP-witness to the claim that the action fits 
the public information). Thus, by Theorem 14.21 it is possible for U 
to efficiently prove the correctness of its action without yielding any¬ 
thing about its secret. Consequently, it is fair to ask U to prove (in 
zero-knowledge) that it behaves properly, and so to force U to behave 
properly. Indeed, “forcing proper behavior” is the canonical application 
of zero-knowledge proofs (see (juj; [bih l. 

This paradigm (i.e., “forcing proper behavior” via zero-knowledge 
proofs), which in turn is based on the fact that zero-knowledge proofs 
can be constructed for any NP-set, has been utilized in numerous differ- 
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ent settings. Indeed, this paradigm is the basis for the wide applicability 
of zero-knowledge protocols in cryptography. 


Zero-knowledge proofs for all IP. For the sake of elegancy, we 
mention that under the same assumption used in the case of J\fV, 
it holds that any set that has an interactive proof also has a zero- 
knowledge interactive proof (cf. (88j; 24)). 


4.4 Variants and issues 

In this section we consider numerous variants on the notion of zero- 
knowledge and the underlying model of interactive proofs. These 
include computational soundness (cf. Section [4.4. II) . black-box simula¬ 
tion and other variants of zero-knowledge (cf. Section 14.4.21) , as well as 
notions such as proofs of knowledge, non-interactive zero-knowledge, 
and witness indistinguishable proofs (cf. Section 14.4.31) . We conclude 
this section by reviewing relatively recent results regarding the com¬ 
position of zero-knowledge protocols and the power of non-black-box 
simulation (cf. Section 14.4.41) . 


4.4.1 Computational soundness 


A fundamental variant on the notion of interactive proofs was intro¬ 
duced by Brassard, Chaurn and Crepeau (1331 ). who relaxed the sound¬ 
ness condition so that it only refers to feasible ways of trying to fool 
the verifier (rather than to all possible ways). Specifically, the sound¬ 
ness condition was replaced by a computational soundness condition 
that asserts that it is infeasible to fool the verifier into accepting false 
statements. We warn that although the computational-soundness error 
can always be reduced by sequential repetitions, it is not true that this 
error can always be reduced by parallel repetitions (cf. (2JJ)). 

Protocols that satisfy the computational-soundness condition are 
called arguments^ We mention that argument systems may be more 
efficient than interactive proofs (see (j9oh vs. (69; 7si)) as well as provide 
stronger zero-knowledge guarantees (see (33) vs. (159: 13 )). Specifically, 


5 A related notion (not discussed here) is that of CS-proofs, introduced by Micali (|99h . 
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perfect zero-knowledge arguments for MV can be constructed based on 
some reasonable assumptions (33)), where perfect zero-knowledge means 
that the simulator’s output is distributed identically to the verifier’s 
view in the real interaction (see discussion in Section [4.4.2p . Note that 
stronger security for the prover (as provided by perfect zero-knowledge) 
comes at the cost of weaker security for the verifier (as provided by 
computational soundness). The answer to the question of whether or 
not this trade-off is worthwhile seems to be application dependent, 
and one should also take into account the availability and complexity 
of the corresponding protocols. (However, as stated in Footnote [Q we 
believe that a presentation in terms of proofs should be preferred for 
expositional purposes.) 


4.4.2 Definitional variations 

We consider several definitional issues regarding the notion of zero- 
knowledge (as defined in Definition 14.11) . 


Universal and black-box simulation. Further strengthening of 
Definition 14.11 is obtained by requiring the existence of a universal sim¬ 
ulator, denoted C, that is given the program of the verifier (i.e., B*) 
as an auxiliary-input; that is, in terms of Definition 14.11 one should 
replace C*(x, z ) by C(x, z, (B*)), where ( B *) denotes the description of 
the program of B* (which may depend on x and on z). That is, we effec¬ 
tively restrict the simulation by requiring that it be a uniform (feasible) 
function of the verifier’s program (rather than arbitrarily depend on it). 
This restriction is very natural, because it seems hard to envision an 
alternative way of establishing the zero-knowledge property of a given 
protocol. Taking another step, one may argue that since it seems infeas¬ 
ible to reverse-engineer programs, the simulator may as well just use 
the verifier strategy as an oracle (or as a “black-box”). This reasoning 
gave rise to the notion of black-box simulation, which was introduced 
and advocated in (j7ll ) and further studied in numerous works (see, 
e.g., (j40()). The belief was that inherent limitations regarding black¬ 
box simulation represent inherent limitations of zero-knowledge itself. 
For example, it was believed that the fact that the parallel version 
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of the interactive proof of Figure l4~2l cannot be simulated in a black¬ 
box manner (unless J\fV is contained in BVV (EH)) implies that this 
version is not zero-knowledge (as per Definition 14.11 itself). However, 
the (underlying) belief that any zero-knowledge protocol can be sim¬ 
ulated in a black-box manner was refuted recently by Barak (8). For 
further discussion, see Section 14.4.41 


Honest verifier versus general cheating verifier. Definition 14.11 
refers to all feasible verifier strategies, which is most natural (in the 
cryptographic setting) because zero-knowledge is supposed to cap¬ 
ture the robustness of the prover under any feasible (i.e., adversarial) 
attempt to gain something by interacting with it. A weaker and still 
interesting notion of zero-knowledge refers to what can be gained by 
an “honest verifier” (or rather a semi-honest verifier jf| that interacts 
with the prover as directed, with the exception that it may maintain 
(and output) a record of the entire interaction (i.e., even if directed 
to erase all records of the interaction). Although such a weaker notion 
is not satisfactory for standard cryptographic applications, it yields a 
fascinating notion from a conceptual as well as a complexity-theoretic 
point of view. Furthermore, as shown in (771:11221. every proof system 
that is zero-knowledge with respect to the honest-verifier can be trans¬ 
formed into a standard zero-knowledge proof (without using intractabil¬ 
ity assumptions and in the case of “public-coin” proofs this is done 
without significantly increasing the prover’s computational effort). 


Statistical versus Computational Zero-Knowledge. Recall that 
Definition UJ] postulates that for every probability ensemble of one type 
(i.e., representing the verifier’s output after interaction with the prover) 
there exists a “similar” ensemble of a second type (i.e., representing 
the simulator’s output). One key parameter is the interpretation of 
“similarity”. Three interpretations, yielding different notions of zero- 


6 The term “honest verifier” is more appealing when considering an alternative (equivalent) 
formulation of Definition 11.11 In the alternative definition (see (:65;, Sec. 4.3.1.3)), the 
simulator is “only” required to generate the verifier’s view of the real interaction, where 
the verifier’s view includes its (common and auxiliary) inputs, the outcome of its coin 
tosses, and all messages it has received. 
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knowledge, have been commonly considered in the literature (cf., (18ll : 

0 ): 

(1) Perfect Zero-Knowledge requires that the two probability 
ensembles be identical^ 

(2) Statistical Zero-Knowledge requires that these probability 
ensembles be statistically close (i.e., the variation distance 
between them is negligible). 

(3) Computational (or rather general) Zero-Knowledge requires 
that these probability ensembles be computationally indis¬ 
tinguishable. 


Indeed, Computational Zero-Knowledge is the most liberal notion, and 
is the notion considered in Definition l4.ll We note that the class of prob¬ 
lems having statistical zero-knowledge proofs contains several prob¬ 
lems that are considered intractable. The interested reader is referred 


to (121). 


Strict versus expected probabilistic polynomial-time. So far, 
we did not specify what we exactly mean by the term probabilistic 
polynomial-time. Two common interpretations are: 


(1) 

( 2 ) 


Strict probabilistic polynomial-time. That is, there exist a 
(polynomial in the length of the input) bound on the number 
of steps in each possible run of the machine, regardless of the 
outcome of its coin tosses. 

Expected probabilistic polynomial-time. The standard 
approach is to look at the running-time as a random variable 
and bound its expectation (by a polynomial in the length 
of the input). As observed by Levin (cf. (1651 . Sec. 4.3.1.6) 
and (0))) this definitional approach is quite problematic 
(e.g., it is not model-independent and is not closed under 
algorithmic composition), and an alternative treatment of 
this random variable is preferable. 


7 The actual definition of Perfect Zero-Knowledge allows the simulator to fail (while out- 
putting a special symbol) with negligible probability, and the output distribution of the 
simulator is conditioned on its not failing. 
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Consequently, the notion of expected polynomial-time raises a variety 
of conceptual and technical problems. For that reason, whenever possi¬ 
ble, one should prefer the more robust (and restricted) notion of strict 
(probabilistic) polynomial-time. Thus, with the exception of constant- 
round zero-knowledge protocols, whenever we talked of a probabilistic 
polynomial-time verifier (resp., simulator) we mean one in the strict 


sense. 


In contrast, with the exception of (J8|; 12), all results regarding 


constant-round zero-knowledge protocols refer to a strict polynomial¬ 
time verifier and an expected polynomial-time simulator, which is 
indeed a small cheat. For further discussion, the reader is referred 
to £i). 


4.4.3 Related notions: POK, NIZK, and WI 

We briefly discuss the notions of proofs of knowledge (POK), non¬ 
interactive zero-knowledge (NIZK), and witness indistinguishable 
proofs (WI). 


Proofs of Knowledge. Loosely speaking, proofs of knowledge 
(cf. (81)) are interactive proofs in which the prover asserts “knowl¬ 
edge” of some object (e.g., a 3-coloring of a graph), and not merely its 
existence (e.g., the existence of a 3-coloring of the graph, which in turn 
is equivalent to the assertion that the graph is 3-colorable). Before clar¬ 
ifying what we mean by saying that a machine knows something, we 
point out that “proofs of knowledge”, and in particular zero-knowledge 
“proofs of knowledge”, have many applications to the design of crypto¬ 
graphic schemes and cryptographic protocols. One famous application 
of zero-knowledge proofs of knowledge is to the construction of identi¬ 
fication schemes (e.g., the Fiat-Shamir scheme (58)). 

What does it mean to say that a machine knows something? Any 
standard dictionary suggests several meanings for the verb to know, 
which are typically phrased with reference to awareness , a notion which 
is certainly inapplicable in the context of machines. We must look for a 
behavioristic interpretation of the verb to know. Indeed, it is reasonable 
to link knowledge with ability to do something (e.g., the ability to write 
down whatever one knows). Hence, we will say that a machine knows 
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a string a if it can output the string a. But this seems total non-sense 
too: a machine has a well-defined output - either the output equals a 
or it does not. So what can be meant by saying that a machine can 
do something? Loosely speaking, it may mean that the machine can 
be easily modified so that it does whatever is claimed. More precisely, 
it may mean that there exists an efficient machine that, using the 
original machine as a black-box (or given its code as an input), outputs 
whatever is claimed. 

So much for defining the “knowledge of machines”. Yet, whatever 
a machine knows or does not know is “its own business”. What can 
be of interest and reference to the outside is whatever can be deduced 
about the knowledge of a machine by interacting with it. Hence, we 
are interested in proofs of knowledge (rather than in mere knowledge). 
For sake of simplicity let us consider a concrete question: how can a 
machine prove that it knows a 3-coloring of a graph? An obvious way is 
just to send the 3-coloring to the verifier. Yet, we claim that applying 
the protocol in Figure l~i~2l (i.e., the zero-knowledge proof system for 3- 
Colorability) is an alternative way of proving knowledge of a 3-coloring 
of the graph. 

The definition of a verifier of knowledge of 3-coloring refers to any 
possible prover strategy. It requires the existence of an efficient uni¬ 
versal way of “extracting” a 3-coloring of a given graph by using any 
prover strategy that convinces the verify to accept the graph (with 
noticeable probability). Surely, we should not expect much of prover 
strategies that convince the verifier to accept the graph with negligible 
probability. However, a robust definition should allow a smooth passage 
from noticeable to negligible, and should allow to establish the intuitive 
zero-knowledge property of a party that sends some information that 
the other party has proved it knows. 

Loosely speaking, we may say that an interactive machine, V, con¬ 
stitutes a verifier for knowledge of 3-coloring if, for any prover strategy 
P, the complexity of extracting a 3-coloring of G when using machine 
P as a “black box”H is inversely proportional to the probability that 
the verifier is convinced by P (to accept the graph G ). Namely, the 


8 Indeed, one may also consider non-black-box extractors as done in 0). 
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extraction of the 3-coloring is done by an oracle machine, called an 
extractor , that is given access to a function specifying the behavior P 
(i.e., the messages it sends in response to particular messages it may 
receive). We require that the (expected) running time of the extrac¬ 
tor, on input G and access to an oracle specifying P’s messages, be 
inversely related (by a factor polynomial in |G|) to the probability 
that P convinces V to accept G. In the case that P always convinces 
V to accept G, the extractor runs in expected polynomial-time. The 
same holds in case P convinces V to accept with noticeable probability. 
On the other hand, in case P never convinces V to accept, essentially 
nothing is required of the extractor. (We stress that the latter special 
cases do not suffice for a satisfactory definition; see discussion in (65, 
Sec. 4.7.1).) 


Non-Interactive Zero-Knowledge. The model of non-interactive 
zero-knowledge proof systems, introduced in (29), consists of three enti¬ 
ties: a prover, a verifier and a uniformly selected reference string (which 
can be thought of as being selected by a trusted third party). Both 
the verifier and prover can read the reference string, and each can 
toss additional coins. The interaction consists of a single message sent 
from the prover to the verifier, who then is left with the final decision 
(whether to accept or not). The (basic) zero-knowledge requirement 
refers to a simulator that outputs pairs that should be computation¬ 
ally indistinguishable from the distribution (of pairs consisting of a 
uniformly selected reference string and a random prover message) seen 
in the real modelj^l Non-interactive zero-knowledge proof systems have 
numerous applications (e.g., to the construction of public-key encryp¬ 
tion and signature schemes, where the reference string may be incorpo¬ 
rated in the public-key). Several different definitions of non-interactive 
zero-knowledge proofs were considered in the literature. 


9 Note that the verifier does not effect the distribution seen in the real model, and so the 
basic definition of zero-knowledge does not refer to it. The verifier (or rather a process of 
adaptively selecting assertions to be proved) will be referred to in the adaptive variants of 
the definition. 
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In the basic definition, one considers proving a single asser¬ 
tion of a-priori bounded length, where this length may be 
smaller than the length of the reference string. 

A natural extension, required in many applications, is the 
ability to prove multiple assertions of varying length, where 
the total length of these assertions may exceed the length of 
the reference string (as long as the total length is polyno¬ 
mial in the length of the reference string). This definition is 
sometimes referred to as the unbounded definition, because 
the total length of the assertions to be proved is not a-priori 
bounded. 

Other natural extensions refer to the preservation of secu¬ 
rity (i.e., both soundness and zero-knowledge) when the 
assertions to be proved are selected adaptively (based on 
the reference string and possibly even based on previous 
proofs). 

Finally, we mention the notion of simulation-soundness, 
which is related to non-malleability. This extension, which 
mixes the zero-knowledge and soundness conditions, refers 
to the soundness of proofs presented by an adversary after 
it obtains proofs of assertions of its own choice (with respect 
to the same reference string). This notion is important in 
applications of non-interactive zero-knowledge proofs to the 
construction of public-key encryption schemes secure against 
chosen ciphertext attacks (see ( 671 Sec. 5.4.4.4)). 


Constructing non-interactive zero-knowledge proofs seems more diffi¬ 
cult than constructing interactive zero-knowledge proofs. Still, based 
on standard intractability assumptions (e.g., intractability of factor¬ 
ing), it is known how to construct a non-interactive zero-knowledge 
proof (even in the adaptive and non-malleable sense) for any NP-set 
(cf. 0; 


Witness Indistinguishability and the FLS-Technique. The 

notion of witness indistinguishability was suggested in (1571) as a 
meaningful relaxation of zero-knowledge. Loosely speaking, for any 
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NP-relation R, a proof (or argument) system for the corresponding 
NP-set is called witness indistinguishable if no feasible verifier may dis¬ 
tinguish the case in which the prover uses one NP-witness to x (i.e., w\ 
such that (x, w \) E R ) from the case in which the prover is using a dif¬ 
ferent NP-witness to the same input x (i.e., W 2 such that (x,u> 2 ) £ R). 
Clearly, any zero-knowledge protocol is witness indistinguishable, but 
the converse does not necessarily hold. Furthermore, it seems that 
witness indistinguishable protocols are easier to construct than zero- 
knowledge ones. Another advantage of witness indistinguishable proto¬ 
cols is that they are closed under arbitrary concurrent composition (1571 ), 
whereas in general zero-knowledge protocols are not closed even under 
parallel composition 0). Witness indistinguishable protocols turned 
out to be an important tool in the construction of more complex proto¬ 
cols ■, as is demonstrated next. 

Feige, Lapidot and Shamir ([560 introduced a technique for con¬ 
structing zero-knowledge proofs (and arguments) based on witness 
indistinguishable proofs (resp., arguments). Following is a sketchy 
description of a special case of their technique, often referred to as 
the FLS-technique, which has been used in numerous works. On com¬ 
mon input x E L, where L is the NP-set defined by the witness relation 
R, the following two steps are performed: 


(1) The parties generate an instance x' for an auxiliary NP- 
set L ', where L' is defined by a witness relation R'. The 
generation protocol in use must satisfy the following two 
conditions: 

(a) If the verifier follows its prescribed strategy then no 
matter which strategy is used by the prover, with high 
probability, the protocol’s outcome is a NO-instance 
of L'. 

(b) Loosely speaking, there exists an efficient (non¬ 
interactive) procedure for producing a (random) 
transcript of the generation protocol such that the 
corresponding protocol’s outcome is a YES-instance of 
L' and yet the produced transcript is computationally 
indistinguishable from the transcript of a real exe- 
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cution of the protocol. Furthermore, this procedure 
also outputs an NP-witness for the YES-instance that 
appears as the protocol’s outcome. 

For example, L' may consist of all possible outcomes of a 
pseudorandom generator that stretches its seed by a factor of 
two, and the generation protocol may consist of the two par¬ 
ties iteratively invoking a “coin tossing” protocol to obtain 
a random string. Note that the outcome of a real execution 
will be an almost uniformly distributed string, which is most 
likely a NO-instance of L', whereas it is easy to generate a 
(random) transcript corresponding to any desired outcome 
(provided that the parties use an adequate coin tossing 
protocol). 

(2) The parties execute a witness indistinguishable proof for 
the NP-set L" defined by the witness relation R" = 
{((a, a'), (/3, /3 1 )) : (a, /3) G R\Z(a', (3 1 ) £ R'}. The sub-protocol 
is such that the corresponding prover can be implemented 
in probabilistic polynomial-time given any NP-witness for 
(a, a') £ L ". The sub-protocol is invoked on common input 
(x, x 1 ), where x' is the outcome of Step 1, and the sub-prover 
is invoked with the corresponding NP-witness as auxiliary 
input (i.e., with (w, 0), where w is the NP-witness for x (given 
to the main prover)). 

The soundness of the above protocol follows by Property (a) of the 
generation protocol (i.e., with high probability x' 0 L', and so x £ L 
follows by the soundness of the protocol used in Step 2). To demonstrate 
the zero-knowledge property, we first generate a simulated transcript of 
Step 1 (with outcome x' £ L') along with an adequate NP-witness (i.e., 
w 1 such that (x', w 1 ) £ R'), and then emulate Step 2 by feeding the sub- 
prover strategy with the NP-witness (0, w'). Combining Property (b) of 
the generation protocol and the witness indistinguishability property 
of the protocol used in Step 2, the simulation is indistinguishable from 
the real execution. 
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4.4.4 Two basic problems: composition and black-box 
simulation 

We conclude this section by considering two basic problems regarding 
zero-knowledge, which actually arise also with respect to the security 
of other cryptographic primitives. 


Composition of protocols. The first question refers to the preser¬ 
vation of security (i.e., zero-knowledge in our case) under various 
types of composition operations. These composition operations rep¬ 
resent independent executions of a protocol that are attacked by an 
adversary (which coordinates its actions in the various executions). The 
preservation of security under such compositions (which involve only 
executions of the same protocol) is a first step towards the study of the 
security of the protocol when executed together with other protocols 
(see further discussion in Section 17.41) . Turning back to zero-knowledge, 
we recall the main facts regarding sequential, parallel and concurrent 
execution of (arbitrary and/or specific) zero-knowledge protocols: 


Sequential composition : As stated above, zero-knowledge (with 
respect to auxiliary inputs) is closed under sequential composi¬ 
tion. 

Parallel composition : In general, zero-knowledge is not closed under 
parallel composition (1711 ). Yet, some zero-knowledge proofs (for 
NP) preserve their security when many copies are executed in 
parallel. Furthermore, some of these protocol use a constant 
number of rounds (cf. (|66l)). 

Concurrent composition: One may view parallel composition as 
concurrent composition in a model of strict synchronity. This 
leads us to consider more general models of concurrent compo¬ 
sition. We distinguish between a model of full asynchronicity 
and a model naturally limited asynchronicity. 

• In the full asynchronous model, some zero-knowledge 
proofs (for NP) preserve their sec urity when many 


copies are executed concurrently (cf. (1111:1911: 107)), but 


such a result is not known for constant-round protocols. 
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• In contrast, constant-round zero-knowledge proofs (for 
NP) are known (cf. (|53j; 166m in a model of limited asyn¬ 
chronicity, where each party holds a local clock such 
that the relative clock rates are bounded by an a-priori 
known constant and the protocols may employ time- 
driven operations (i.e., time-out incoming messages and 
delay out-going messages). 

The study of zero-knowledge in the concurrent setting provides a good 
test case for the study of concurrent security of general protocols. In 
particular, the results in (71; 4d|) point out inherent limitations of the 
“standard proof methods” (used to establish zero-knowledge) when 
applied to the concurrent setting, where ( 1711 ) treats the synchronous 
case and (40) uncovers much stronger limitations for the asynchronous 
case. By “standard proof methods” we refer to the establishment of 
zero-knowledge via a single simulator that obtains only oracle (or 
“black-box”) access to the adversary procedure. 


Black-box proofs of security. The second basic question regarding 
zero-knowledge refers to the usage of the adversary’s program within 
the proof of security (i.e., demonstration of the zero-knowledge prop¬ 
erty). For 15 years, all known proofs of security used the adversary’s 
program as a black-box (i.e., a universal simulator was presented using 
the adversary’s program as an oracle). Furthermore, it was believed 
that there was no advantage in having access to the code of the adver¬ 
sary’s program (cf. (71))- Consequently it was conjectured that negative 
results regarding black-box simulation represent an inherent limitation 
of zero-knowledge. This belief has been refuted recently by Barak (sf) 
who constructed a zero-knowledge argument (for NP) that has impor¬ 
tant properties that are impossible to achieve by black-box simulation 
(unless MV C BVV). For example, this zero-knowledge argument uses 
a constant number of rounds and preserves its security when an a-priori 
fixed (polynomial) number of copies are executed concurrently! 10 ! 


10 This result falls short of achieving a fully concurrent zero-knowledge argument, because 
the number of concurrent copies must be fixed before the protocol is presented. Specifi¬ 
cally, the protocol uses messages that are longer than the allowed number of concurrent 
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Barak’s results (cf. (8;) and also (9f)) call for the re-evaluation of 
many common beliefs. Most concretely, they say that results regard¬ 
ing black-box simulators do not reflect inherent limitations of zero- 
knowledge (but rather an inherent limitation of a natural way of demon¬ 
strating the zero-knowledge property). Most abstractly, they say that 
there are meaningful ways of using a program other than merely invok¬ 
ing it as a black-box. Does this mean that a method was found to 
“reverse engineer” programs or to “understand” them? We believe that 
the answer is negative. Barak (3) is using the adversary’s program in 
a significant way (i.e., more significant than just invoking it), without 
“understanding” it. 

The key idea underlying Barak’s protocol |§) is to have the prover 
prove that either the original NP-assertion is valid or that he (i.e., 
the prover) “knows the verifier’s residual strategy” (in the sense that 
it can predict the next verifier message). Indeed, in a real interaction 
(with the honest verifier), it is infeasible for the prover to predict the 
next verifier message, and so computational-soundness of the protocol 
follows. However, a simulator that is given the code of the verifier’s 
strategy (and not merely oracle access to that code), can produce a valid 
proof of the disjunction by properly executing the sub-protocol using its 
knowledge of an NP-witness for the second disjunctive. The simulation 
is computationally indistinguishable from the real execution, provided 
that one cannot distinguish an execution of the sub-protocol in which 
one NP-witness (i.e., an NP-witness for the original assertion) is used 
from an execution in which the second NP-witness (i.e., an NP-witness 
for the auxiliary assertion) is used. That is, the sub-protocol should be a 
witness indistinguishable argument system, and the entire construction 
uses the FLS technique (described in Section f4. 4. 31) . We warn the reader 
that the actual implementation of the above idea requires overcoming 
several technical difficulties (cf. 


11 ))- 


copies. However, even preservation of security under an a priori bounded number of 
executions goes beyond the impossibility results of QS3) (which refers to black-box 
simulations). 






Part II 

Basic Applications 


56 



57 


Encryption and signature schemes are the most basic applications of 
cryptography. Their main utility is in providing secret and reliable 
communication over insecure communication media. Loosely speaking, 
encryption schemes are used to ensure the secrecy (or privacy) of the 
actual information being communicated, whereas signature schemes are 
used to ensure its reliability (or authenticity). In this part we survey 
these basic applications as well as the construction of general secure 
cryptographic protocols. For more details regarding the contents of the 
current part, see our recent textbook (67|) - 




5 


Encryption Schemes 


The problem of providing secret communication over insecure media is 
the traditional and most basic problem of cryptography. The setting of 
this problem consists of two parties communicating through a channel 
that is possibly tapped by an adversary. The parties wish to exchange 
information with each other, but keep the “wire-tapper” as ignorant 
as possible regarding the contents of this information. The canonical 
solution to the above problem is obtained by the use of encryption 
schemes. Loosely speaking, an encryption scheme is a protocol allow¬ 
ing these parties to communicate secretly with each other. Typically, 
the encryption scheme consists of a pair of algorithms. One algorithm, 
called encryption, is applied by the sender (i.e., the party sending a mes¬ 
sage), while the other algorithm, called decryption, is applied by the 
receiver. Hence, in order to send a message, the sender first applies 
the encryption algorithm to the message, and sends the result, called 
the ciphertext, over the channel. Upon receiving a ciphertext, the other 
party (i.e., the receiver) applies the decryption algorithm to it, and 
retrieves the original message (called the plaintext). 

In order for the above scheme to provide secret communication, the 
communicating parties (at least the receiver) must know something 
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that is not known to the wire-tapper. (Otherwise, the wire-tapper can 
decrypt the ciphertext exactly as done by the receiver.) This extra 
knowledge may take the form of the decryption algorithm itself, or some 
parameters and/or auxiliary inputs used by the decryption algorithm. 
We call this extra knowledge the decryption-key. Note that, without loss 
of generality, we may assume that the decryption algorithm is known 
to the wire-tapper, and that the decryption algorithm operates on two 
inputs: a ciphertext and a decryption-key. We stress that the existence 
of a decryption-key, not known to the wire-tapper, is merely a necessary 
condition for secret communication. The above description implicitly 
presupposes the existence of an efficient algorithm for generating (ran¬ 
dom) keys. 

Evaluating the “security” of an encryption scheme is a very tricky 
business. A preliminary task is to understand what is “security” (i.e., to 
properly define what is meant by this intuitive term). Two approaches 
to defining security are known. The first (“classical”) approach, intro¬ 
duced by Shannon 0), is information theoretic. It is concerned with 
the “information” about the plaintext that is “present” in the cipher- 
text . Loosely speaking, if the ciphertext contains information about 
the plaintext then the encryption scheme is considered insecure. It has 
been shown that such high (i.e., “perfect”) level of security can be 
achieved only if the key in use is at least as lon g as the total amount 
of information sent via the encryption scheme (119:1. This fact (i.e., 
that the key has to be longer than the information exchanged using 
it) is indeed a drastic limitation on the applicability of such (perfectly- 
secure) encryption schemes. 

The second (“modern”) approach, followed in the current text, is 
based on computational complexity. This approach is based on the the¬ 
sis that it does not matter whether the ciphertext contains information 
about the plaintext, but rather whether this information can be effi¬ 
ciently extracted. In other words, instead of asking whether it is possible 
for the wire-tapper to extract specific information, we ask whether it is 
feasible for the wire-tapper to extract this information. It turns out that 
the new (i.e., “computational complexity”) approach can offer security 
even when the key is much shorter than the total length of the messages 
sent via the encryption scheme. 
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The key-pair (e, d) is generated hy the receiver, who posts the 
encryption-key e on a public media, while keeping the decryption- 
key d secret. 

Fig. 5.1 Public-key encryption schemes - an illustration. 


The computational complexity approach enables the introduction of 
concepts and primitives that cannot exist under the information theo¬ 
retic approach. A typical example is the concept of public-key encryp¬ 
tion schemes , introduced by Diffie and Heilman (1491) . Recall that in the 
above discussion we concentrated on the decryption algorithm and its 
key. It can be shown that the encryption algorithm must get, in addition 
to the message, an auxiliary input that depends on the decryption-key. 
This auxiliary input is called the encryption-key. Traditional encryp¬ 
tion schemes, and in particular all the encryption schemes used in the 
millennia until the 1980s, operate with an encryption-key that equals 
the decryption-key. Hence, the wire-tapper in these schemes must be 
ignorant of the encryption-key, and consequently the key distribution 
problem arises; that is, how can two parties wishing to communicate 
over an insecure channel agree on a secret encryption/decryption key. 
(The traditional solution is to exchange the key through an alterna¬ 
tive channel that is secure though (much) more expensive to use.) 
The computational complexity approach allows the introduction of 
encryption schemes in which the encryption-key may be given to the 
wire-tapper without compromising the security of the scheme. Clearly, 
the decryption-key in such schemes is different from the encryption- 
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key, and furthermore infeasible to compute from the encryption-key. 
Such encryption schemes, called public-key schemes, have the advan¬ 
tage of trivially resolving the key distribution problem (because the 
encryption-key can be publicized). That is, once some Party X gener¬ 
ates a pair of keys and publicizes the encryption-key, any party can 
send encrypted messages to Party X so that Party X can retrieve the 
actual information (i.e., the plaintext), whereas nobody else can learn 
anything about the plaintext. 



The key K is known to both receiver and sender, but is unknown 
to the adversary. For example, the receiver may generate K at 
random and pass it to the sender via a perfectly-private sec¬ 
ondary channel (not shown here). 

Fig. 5.2 Private-key encryption schemes - an illustration. 


In contrast to public-key schemes, traditional encryption schemes in 
which the encryption-key equals the description-key are called private- 
key schemes, because in these schemes the encryption-key must be kept 
secret (rather than be public as in public-key encryption schemes). We 
note that a full specification of either schemes requires the specifica¬ 
tion of the way in which keys are generated; that is, a (randomized) 
key-generation algorithm that, given a security parameter, produces a 
(random) pair of corresponding encryption/decryption keys (which are 
identical in the case of private-key schemes). 

Thus, both private-key and public-key encryption schemes consist 
of three efficient algorithms: a key generation algorithm denoted G, an 
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encryption algorithm denoted E, and a decryption algorithm denoted 
D. For every pair of encryption and decryption keys (e, d) generated 
by G, and for every plaintext x, it holds that Dd(E e (x)) = x, where 
E e (x) = f E(e, x) and Dd(y) = f D(d, y). The difference between the two 
types of encryption schemes is reflected in the definition of security: the 
security of a public-key encryption scheme should hold also when the 
adversary is given the encryption-key, whereas this is not required for a 
private-key encryption scheme. Below we focus on the public-key case 
(and the private-key case can be obtained by omitting the encryption- 
key from the sequence of inputs given to the adversary). 

5.1 Definitions 

A good disguise should not reveal the person’s height. 

Shah Goldwasser and Silvio Micali, 1982 

For simplicity, we first consider the encryption of a single message 
(which, for further simplicity, is assumed to be of length n ) U As implied 
by the above discussion, a public-key encryption scheme is said to be 
secure if it is infeasible to gain any information about the plaintext by 
looking at the ciphertext (and the encryption-key). That is, whatever 
information about the plaintext one may compute from the cipher- 
text and some a-priori information, can be essentially computed as 
efficiently from the a-priori information alone. This fundamental defi¬ 
nition of security (called semantic security) turns out to be equivalent 
to saying that, for any two messages, it is infeasible to distinguish 
the encryption of the first message from the encryption of the second 
message, even when given the encryption-key. Both definitions were 
introduced by Goldwasser and Micali (8(j). 


Definition 5.1. (semantic security (following (8C), revisited SH)): 
A public-key encryption scheme ( G,E,D) is semantically secure if for 


1 In the case of public-key schemes no generality is lost by these simplifying assumptions, 
but in the case of private-key schemes one should consider the encryption of polynomially- 
many messages (as we do below). 
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every probabilistic polynomial-time algorithm. A, there exists a prob¬ 
abilistic polynomial-time algorithm B so that for every two functions 
f,h : {0,1}* —> {0,1}* such that |/i(a;)| = poly(|cc|), and all probabil¬ 
ity ensembles {X n } ng pj, where X n is a random variable ranging over 
{0, l} n , it holds that 

Pr[A(e,E e (x),h(x)) = f(x)\ < Pr[B(l n ,h(x)) = f{x)} + y(n). 

where the plaintext x is distributed according to X n , the encryption- 
key e is distributed according to G(l n ), and y is a negligible function. 


That is, it is feasible to predict f(x) from h(x) as successfully as it is 
to predict f(x) from h(x) and (e,E e (x)), which means that nothing 
is gained by obtaining (e,E e (x)). Note that no computational restric¬ 
tions are made regarding the functions h and /. We stress that the 
above definition (as well as the next one) refers to public-key encryp¬ 
tion schemes, and in the case of private-key schemes algorithm A is not 
given the encryption-key e. 


A good disguise should not allow a mother 
to distinguish her own children. 

Shah Goldwasser and Silvio Micali, 1982 

The following technical interpretation of security states that it is infeas¬ 
ible to distinguish the encryptions of two plaintext s (of the same 
length). 


Definition 5.2. (indistinguishability of encryptions (following (8(1))): 
A public-key encryption scheme ( G,E,D ) has indistinguishable encryp¬ 
tions if for every probabilistic polynomial-time algorithm, A, and all 
sequences of triples, (x n , y n , £ n )neN, where \x n \ = \y n \ = n and 
\z n \ = poly(n), 

|Pr[A(e, E e (x n ),z n ) = 1] - Pr[A(e, E e (y n ), z n ) = 1]| = fi{n). 

Again, e is distributed according to G{ l n ), and y is a negligible func¬ 
tion. 
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In particular, z n may equal (x n , y n ). Thus, it is infeasible to distinguish 
the encryptions of any two fixed messages (such as the all-zero message 
and the all-ones message). 

Definition 15.II is more appealing in most settings where encryption is 
considered the end goal. Definition 15.21 is used to establish the security 
of candidate encryption schemes as well as to analyze their application 
as modules inside larger cryptographic protocols. Thus, their equiva¬ 
lence is of major importance. 

Equivalence of Definitions 15.11 and 15.21 proof ideas. Intu¬ 
itively, indistinguishability of encryptions (i.e., of the encryptions of 
x n and y n ) is a special case of semantic security; specifically, it 
corresponds to the case that X n is uniform over {x n ,y n }, f indi¬ 
cates one of the plaintext s and h does not distinguish them (i.e., 
f(w) = 1 iff w = x n and h(x n ) = h(y n ) = z n , where z n is 
as in Definition 15.21) . The other direction is proved by considering 
the algorithm B that, on input (l n ,u) where v = h(x), generates 
(e,d) <— G{\ n ) and outputs A(e,E e (l n ),v), where A is as in Defini¬ 
tion 15.11 Indistinguishability of encryptions is used to prove that B 
performs as well as A (i.e., for every h, f and {^ n }neN) it holds that 
Pr[B(l'\ h(X n )) = f(X n )} = Pr [A(e, E e (l n ), h(X n )) = f(X n )} approxi¬ 
mately equals Pr [A(e,E e (X n ),h(X n )) = f(X n )]). 


Probabilistic encryption: It is easy to see that a secure public- 
key encryption scheme must employ a probabilistic (i.e., randomized) 
encryption algorithm. Otherwise, given the encryption-key as (addi¬ 
tional) input, it is easy to distinguish the encryption of the all-zero 
message from the encryption of the all-ones messaged This explains 
the association of the aforementioned robust security definitions and 
probabilistic encryption , an association that goes back to the title of 
the pioneering work of Goldwasser and Micali (80). 


2 The same holds for (stateless) private-key encryption schemes, when considering the secu- 
rity of encrypting several messages (rather than a single message as done above). For 
example, if one uses a deterministic encryption algorithm then the adversary can distin¬ 
guish two encryptions of the same message from the encryptions of a pair of different 
messages. 
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Further discussion: We stress that (the equivalent) Definitions 15.11 
and 15.21 go way beyond saying that it is infeasible to recover the plain¬ 
text from the ciphertext . The latter statement is indeed a minimal 
requirement from a secure encryption scheme, but is far from being 
a sufficient requirement. Typically, encryption schemes are used in 
applications where even obtaining partial information on the plain¬ 
text may endanger the security of the application. When designing 
an application-independent encryption scheme, we do not know which 
partial information endangers the application and which does not. Fur¬ 
thermore, even if one wants to design an encryption scheme tailored to 
a specific application, it is rare (to say the least) that one has a precise 
characterization of all possible partial information that endanger this 
application. Thus, we need to require that it is infeasible to obtain any 
information about the plaintext from the ciphertext . Furthermore, in 
most applications the plaintext may not be uniformly distributed and 
some a-priori information regarding it is available to the adversary. We 
require that the secrecy of all partial information is preserved also in 
such a case. That is, even in presence of a-priori information on the 
plaintext , it is infeasible to obtain any (new) information about the 
plaintext from the ciphertext (beyond what is feasible to obtain from 
the a-priori information on the plaintext ). The definition of semantic 
security postulates all of this. The equivalent definition of indistin- 
guishability of encryptions is useful in demonstrating the security of 
candidate constructions as well as for arguing about their effect as part 
of larger protocols. 

Security of multiple messages: Definitions 15 .1 1 and 15.21 refer to the 
security of an encryption scheme that is used to encrypt a single plain¬ 
text (per generated key). Since the plaintext may be longer than the 
keyjl these definitions are already non-trivial, and an encryption scheme 
satisfying them (even in the private-key model) implies the existence 
of one-way functions. Still, in many cases, it is desirable to encrypt 

3 Recall that for sake of simplicity we have considered only messages of length n, but the 
general definitions refer to messages of arbitrary (polynomial in n) length. We comment 
that, in the general form of Definition I5.ll one should provide the length of the message 
as an auxiliary input to both algorithms (A and B). 
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many plaintext s using the same encryption-key. Loosely speaking, an 
encryption scheme is secure in the multiple-messages setting if analo¬ 
gous definitions (to Definitions 15.11 and 15.21) hold when polynomially- 
rnany plaintext s are encrypted using the same encryption-key (cf. (1671 , 
Sec. 5.2.4)). It is easy to see that in the public-key model , security in the 
single-message setting implies security in the multiple-messages setting. 
We stress that this is not necessarily true for the private-key model. 


5.2 Constructions 

It is common practice to use “pseudorandom generators” as a basis for 
private-key encryption schemes. We stress that this is a very dangerous 
practice when the “pseudorandom generator” is easy to predict (such as 
the linear congruential generator or some modifications of it that output 
a constant fraction of the bits of each resulting number). However, 
this common practice becomes sound provided one uses pseudorandom 
generators (as defined in Section f3.21) . An alternative and more flexible 
construction follows. 


Private-key encryption scheme based on pseudorandom func¬ 
tions: We present a simple construction that uses pseudorandom 
functions as defined in Section 13.31 The key generation algorithm con¬ 
sists of selecting a seed, denoted s, for a (pseudorandom) function, 
denoted f s . To encrypt a message x E {0,1}" (using key s), the encryp¬ 
tion algorithm uniformly selects a string r E {0, l} n and produces the 
ciphertext (r, x(Bf s (r)), where © denotes the exclusive-or of bit strings. 
To decrypt the ciphertext (r,y) (using key s), the decryption algo¬ 
rithm just computes y © / s (r). The proof of security of this encryption 
scheme consists of two steps (suggested as a general methodology in 
Section 13.31) : 

(1) Prove that an idealized version of the scheme, in which one 
uses a uniformly selected function F: {0, l} n —► {0, l} n , rather 
than the pseudorandom function f s , is secure. 

(2) Conclude that the real scheme (as presented above) is secure 
(because, otherwise one could distinguish a pseudorandom 
function from a truly random one). 
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Note that we could have gotten rid of the randomization (in the encryp¬ 
tion process) if we had allowed the encryption algorithm to be history- 
dependent (e.g., use a counter in the role of r). This can be done pro¬ 
vided that either only one party uses the key for encryption (and main¬ 
tains a counter) or that all parties that encrypt, using the same key, 
coordinate their actions (i.e., maintain a joint state (e.g., counter)). 
Indeed, when using a private-key encryption scheme, a common situa¬ 
tion is that the same key is only used for communication between two 
specific parties, which update a joint counter during their communi¬ 
cation. Furthermore, if the encryption scheme is used for FIFO com¬ 
munication between the parties and both parties can reliably maintain 
the counter value, then there is no need (for the sender) to send the 
counter value. (The resulting scheme is related to “stream ciphers” that 
are commonly used in practice.) 

We comment that the use of a counter (or any other state) in the 
encryption process is not reasonable in the case of public-key encryp¬ 
tion schemes, because it is incompatible with the canonical usage of 
such schemes (i.e., allowing all parties to send encrypted messages to 
the “owner of the encryption-key” without engaging in any type of fur¬ 
ther coordination or communication). Furthermore, as discussed before, 
probabilistic encryption is essential for a secure public-key encryption 
scheme even in the case of encrypting a single message (unlike in the 
case of private-key schemes). Following Goldwasser and Micali |scj), we 
now demonstrate the use of probabilistic encryption in the construction 
of a public-key encryption scheme. 

Public-key encryption scheme based on trapdoor permuta¬ 
tions: We present two constructions that employ a collection of trap¬ 
door permutations, as defined in Definition 12.31 Let {fi : Di —> Df\i be 
such a collection, and let b be a corresponding hard-core predicate. The 
key generation algorithm consists of selecting a permutation f, along 
with a corresponding trapdoor t, and outputting (i, t ) as the key-pair. 
To encrypt a ( single ) bit a (using the encryption-key i), the encryp¬ 
tion algorithm uniformly selects r 6 D;, and produces the ciphertext 
(fi(r), a®b(r)). To decrypt the ciphertext (y, r) (using the decryption- 
key t). the decryption algorithm computes r © b{f~ 1 {y )) (using the 
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trapdoor t of fi). Clearly, ( a © b(r)) © b(ff 1 (fi(r))) = a. Indistin- 
guishability of encryptions can be easily proved using the fact that b is 
a hard-core of fi. We comment that the above scheme is quite waste¬ 
ful in bandwidth; however, the paradigm underlying its construction 
(i.e., applying the trapdoor permutation to a randomized version of the 
plaintext rather than to the actual plaintext ) is valuable in practice. 
A more efficient construction of a public-key encryption scheme, which 
uses the same key-generation algorithm, follows. To encrypt an i- bit 
long string x (using the encryption-key i), the encryption algorithm 
uniformly selects r G Di, computes y <— b(r) ■ b(fi(r)) ■ ■ ■ b(f^~ 1 (r)) 
and produces the ciphertext (ff(r),x © y). To decrypt the cipher- 
text (u,v) (using the decryption-key t), the decryption algorithm first 
recovers r = f~ e {u) (using the trapdoor t of fi), and then obtains 
v © b(r) ■ b(fi(r )) • • • 6(// _1 (r)). Note the similarity to the construction 
in Theorem 13.31 and the fact that the proof can be extended to estab¬ 
lish the computational indistinguishability of (6(r) • • • b(f^ 1 (r)), f£(r)) 
and (r',fi(r)), for random and independent r G Di and r' G {0,1}^. 
Indistinguishability of encryptions follows, and thus the aforementioned 
scheme is secure. 


Concrete implementations of the aforementioned public-key 
encryption schemes: For the first scheme, we are going to use the 
RSA scheme fill) as a trapdoor permutation (rather than using it 
directly as an encryption scheme) o The RSA scheme has an instance¬ 
generating algorithm that randomly selects two primes, p and q. com¬ 
putes their product N = p ■ q, and selects at random a pair of integers 
(e, d) such that e ■ d = 1 (mod (j>(N)), where 4>(N) = f (p— 1) ■ (q — 1). 
(The “plain RSA” operations are raising to power e or d modulo N.) 
We construct a public-key encryption scheme as follows: The key- 
generation algorithm is identical to the instance-generator algorithm of 
RSA, and the encryption-key is set to (N, e) (resp., the decryption-key 
is set to (N, d)), just as in “plain RSA”. To encrypt a single bit a (using 


4 Recall that RSA itself is not semantically secure, because it employs a deterministic 
encryption algorithm. The scheme presented here can be viewed as a “randomized version” 
of RSA. 
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Key-generation on security parameter n: 

(1) Select at random two n-bit primes, P and Q, each congruent to 
3 mod 4. 

(2) Compute dp = ((P + l)/4) ( ( n i mod P — 1, dQ = ((Q + 

l)/4mod Q — 1, cp = Q ■ (Q -1 mod P), and cq = P ■ 
(P~ 1 mod Q). 

The output key-pair is ( N,T ), where N = PQ and T = 
( PQ, N, c P , dp, CQ,dQ). 

(Note: for every s, it holds that (s 2 )^”*" 1 ^ 4 = s (mod P), and so 

(^ 2 c(n)) dp _ ^ ( moc j p). Thus, raising to the dp -th power modulo P is 
equivalent to taking the 2^-th root modulo P. To recover roots modulo N , we 
use the Chinese Remainder Theorem with the corresponding coefficients cp 
and cq.) 

Encryption of message x E {0, using the encryption-key N: 

(1) Uniformly select so E {1,A^}. 

(2) For i = 1, + 1, compute Si s?_ 1 mod N and cii = lsb(si). 

The ciphertext is (sg( n )+i, y ), where y = x © cj\<J 2 ■ ■ • cr^( n ) • 

(Note: si plays the role played by r in the general scheme.) 

Decryption of the ciphertext (r, y) using the encryption-key T = 

(P, Q , N , cp, dp,CQ,dQ ): 

(1) Let s' <— r dp mod P, and s" <— r d Q mod Q. 

(2) Let si «— cp • s' + cq • s" mod N. 

(3) For i = l, ..,£(n), compute cr^ = lsb(si) and s^-i-i s| mod N. 

The plaintext is y © cj\(J 2 • • • cr^( n ) • 

Note: lsb is a hard-core of the modular squaring function Q). 


Fig. 5.3 The Blum-Goldwasser Public-Key Encryption Scheme ©• For simplicity we 
assume that which is polynomially bounded (e.g., £(n) = n), is known at key-generation 
time. 


the encryption-key (N,e)), the encryption algorithm uniformly selects 
an element, r, in the set of residues mod N, and produces the ciphertext 
(r e mod N, a © lsb(r)), where lsb(r) denotes the least significant bit of 
r (which is a hard-core of the RSA function (js 1 )). To decrypt the cipher- 
text (y,r) (using the decryption-key ( N,d )), the decryption algorithm 
just computes r © lsb(y rf mod N). Turning to the second scheme, we 
assume the intractability of factoring large integers, and use squaring 
modulo a composite as a trapdoor permutation over the corresponding 
quadratic residues (while using composites that are the product of two 
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primes, each congruent to 3 modulo 4). The resulting secure public-key 
encryption scheme, depicted in Figure [5731 has efficiency comparable to 
that of (plain) RSA. We comment that special properties of modular 
squaring were only used (in Figure 15.31) to speed-up the computation 
of (i.e., rather than iteratively extracting modular square roots l 

times, we extracted the modular 2^-th root). 


5.3 Beyond eavesdropping security 


Our treatment so far has referred only to a “passive” attack in which 
the adversary merely eavesdrops on the line over which ciphertext s 
are being sent. Stronger types of attacks, culminating in the so-called 
Chosen Ciphertext Attack, may be possible in various applications. 
Specifically, in some settings it is feasible for the adversary to make 
the sender encrypt a message of the adversary’s choice, and in some 
settings the adversary may even make the receiver decrypt a cipher- 
text of the adversary’s choice. This gives rise to chosen plaintext attacks 
and to chosen ciphertext attacks, respectively, which are not covered by 
the security definitions considered in previous sections. In this section 
we briefly discuss such “active” attacks, focusing on chosen ciphertext 
attacks (of the stronger type known as “a posteriori” or “CCA2”). 

Loosely speaking, in a chosen ciphertext attack, the adversary may 
obtain the decryptions of ciphertext s of its choice, and is deemed suc¬ 
cessful if it learns something regarding the plaintext that corresponds 
to some different ciphertext (see 189:1191) and (1671 . Sec. 5.4.4)). That is, 
the adversary is given oracle access to the decryption function corre¬ 
sponding to the decryption-key in use (and, in the case of private-key 
schemes, it is also given oracle access to the corresponding encryption 
function). The adversary is allowed to query the decryption oracle on 
any ciphertext except for the “test ciphertext ” (i.e., the very ciphertext 
for which it tries to learn something about the corresponding plain¬ 
text). It may also make queries that do not correspond to legitimate 
ciphertext s, and the answer will be accordingly (i.e., a special “failure” 
symbol). Furthermore, the adversary may effect the selection of the test 
ciphertext (by specifying a distribution from which the corresponding 
plaintext is to be drawn). 
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Private-key and public-key encryption schemes secure against cho¬ 
sen ciphertext attacks can be constructed under (almost) the same 
assumptions that suffice for the construction of the corresponding pas¬ 
sive schemes. Specifically: 


Theorem 5.3. (folklore, see 1(67. Sec. 5 . 4 . 4 .3)): Assuming the exis¬ 
tence of one-way functions, there exist private-key encryption schemes 
that are secure against chosen ciphertext attack. 


Theorem 5.4. ( llOA : 5C), using 


Assuming the existence of enhance 1 


'i 


2f> I; \5a) . see 67 . Sec. 5.4-4-4)) : 
trapdoor permutations, there exist 


public-key encryption schemes that are secure against chosen ciphertext 
attack. 


Both theorems are proved by constructing encryption schemes in which 
the adversary’s gain from a chosen ciphertext attack is eliminated by 
making it infeasible (for the adversary) to obtain any useful knowl¬ 
edge via such an attack. In the case of private-key schemes (i.e., 
Theorem 15.31) , this is achieved by making it infeasible (for the adver¬ 
sary) to produce legitimate ciphertext s (other than those explic¬ 
itly given to it, in response to its request to encrypt plaintext s of 
its choice). This, in turn, is achieved by augmenting the ciphertext 
with an “authentication tag” that is hard to generate without knowl¬ 
edge of the encryption-key; that is, we use a message-authentication 
scheme (as defined in Section |6|). In the case of public-key schemes 
(i.e., Theorem 15.41) . the adversary can certainly generate ciphertext s 
by itself, and the aim is to to make it infeasible (for the adversary) to 
produce legitimate ciphertext s without “knowing” the corresponding 
plaintext . This, in turn, will be achieved by augmenting the plain¬ 
text with a non-interactive zero-knowledge “proof of knowledge” of the 
corresponding plaintext . 

5 Loosely speaking, the enhancement refers to the hardness condition of Definition ^. 21 and 
requires that it be hard to recover /r 1 (y) also when given the coins used to sample y 
(rather than merely y itself). See (67), Apdx. C.l). 
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Security against chosen ciphertext attack is related to the notion of 
non-malleability of the encryption scheme (cf. (50)). Loosely speaking, 
in a non-malleable encryption scheme it is infeasible for an adversary, 
given a ciphertext , to produce a valid ciphertext for a related plain¬ 
text (e.g., given a ciphertext of a plaintext 1®, for an unknown x, it 
is infeasible to produce a ciphertext to the plaintext Ox). For further 


discussion see (|5Qj; 19j; 89). 









6 


Signature and Message Authentication Schemes 


Both signature schemes and message authentication schemes are meth¬ 
ods for “validating” data; that is, verifying that the data was approved 
by a certain party (or set of parties). The difference between signa¬ 
ture schemes and message authentication schemes is that signatures 
should be “universally verifiable”, whereas authentication tags are only 
required to be verifiable by parties that are also able to generate them. 


Signature Schemes: The need to discuss “digital signatures” (1491 ; 


1081 1 has arisen with the introduction of computer communication to 


the business environment (in which parties need to commit them¬ 
selves to proposals and/or declarations that they make). Discussions 
of “unforgeable signatures” did take place also in previous centuries, 
but the objects of discussion were handwritten signatures (and not dig¬ 
ital ones), and the discussion was not perceived as related to “crypto¬ 
graphy”. Loosely speaking, a scheme for unforgeable signatures should 
satisfy the following: 


• each user can efficiently produce its own signature on docu¬ 
ments of its choice; 


75 
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• every user can efficiently verify whether a given string is a 
signature of another (specific) user on a specific document; 
but 

• it is infeasible to produce signatures of other users to docu¬ 
ments they did not sign. 

We note that the formulation of unforgeable digital signatures provides 
also a clear statement of the essential ingredients of handwritten sig¬ 
natures. The ingredients are each person’s ability to sign for itself, a 
universally agreed verification procedure, and the belief (or assertion) 
that it is infeasible (or at least hard) to forge signatures (i.e., produce 
some other person’s signatures to documents that were not signed by it 
such that these “unauthentic” signatures are accepted by the verifica¬ 
tion procedure). It is not clear to what extent handwritten signatures 
meet these requirements. In contrast, our discussion of digital signa¬ 
tures provides precise statements concerning the extent to which digi¬ 
tal signatures meet the above requirements. Furthermore, unforgeable 
digital signature schemes can be constructed based on some reasonable 
computational assumptions (i.e., the existence of one-way functions). 


Message authentication schemes: Message authentication is a 
task related to the setting considered for encryption schemes; that 
is, communication over an insecure channel. This time, we consider 
an active adversary that is monitoring the channel and may alter the 
messages sent on it. The parties communicating through this insecure 
channel wish to authenticate the messages they send so that their coun¬ 
terpart can tell an original message (sent by the sender) from a modified 
one (i.e., modified by the adversary). Loosely speaking, a scheme for 
message authentication should satisfy the following: 

• each of the communicating parties can efficiently produce an 
authentication tag to any message of its choice; 

• each of the communicating parties can efficiently verify 
whether a given string is an authentication tag of a given 
message; but 
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• it is infeasible for an external adversary (i.e., a party other 
than the communicating parties) to produce authentication 
tags to messages not sent by the communicating parties. 

Note that in contrast to the specification of signature schemes we do not 
require universal verification: only the designated receiver is required 
to be able to verify the authentication tags. Furthermore, we do not 
require that the receiver cannot produce authentication tags by itself 
(i.e., we only require that external parties cannot do so). Thus, message 
authentication schemes cannot convince a third party that the sender 
has indeed sent the information (rather than the receiver having gener¬ 
ated it by itself). In contrast, signatures can be used to convince third 
parties: in fact, a signature to a document is typically sent to a second 
party so that in the future this party may (by merely presenting the 
signed document) convince third parties that the document was indeed 
generated (or sent or approved) by the signer. 

6.1 Definitions 

Formally speaking, both signature schemes and message authentica¬ 
tion schemes consist of three efficient algorithms: key generation, sign¬ 
ing and verification. As in the case of encryption schemes, the key- 
generation algorithm is used to generate a pair of corresponding keys, 
one is used for signing and the other is used for verification. The dif¬ 
ference between the two types of schemes is reflected in the definition 
of security. In the case of signature schemes, the adversary is given the 
verification-key, whereas in the case of message authentication schemes 
the verification-key (which may equal the signing-key) is not given to 
the adversary. Thus, schemes for message authentication can be viewed 
as a private-key version of signature schemes. This difference yields dif¬ 
ferent functionalities (even more than in the case of encryption): In the 
typical use of a signature scheme, each user generates a pair of sign¬ 
ing and verification keys, publicizes the verification-key and keeps the 
signing-key secret. Subsequently, each user may sign documents using 
its own signing-key, and these signatures are universally verifiable with 
respect to its public verification-key. In contrast, message authentica¬ 
tion schemes are typically used to authenticate information sent among 
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a set of mutually trusting parties that agree on a secret key, which is 
being used both to produce and verify authentication-tags. (Indeed, 
it is assumed that the mutually trusting parties have generated the 
key together or have exchanged the key in a secure way, prior to the 
communication of information that needs to be authenticated.) 

We focus on the definition of secure signature schemes. Following 
Goldwasser, Micali and Rivest (I82i ). we consider very powerful attacks 
on the signature scheme as well as a very liberal notion of breaking it. 
Specifically, the attacker is allowed to obtain signatures to any message 
of its choice. One may argue that in many applications such a general 
attack is not possible (because messages to be signed must have a spe¬ 
cific format). Yet, our view is that it is impossible to define a general 
(i.e., application-independent) notion of admissible messages, and thus 
a general/robust definition of an attack seems to have to be formulated 
as suggested here. (Note that, at worst, our approach is overly cau¬ 
tious.) Likewise, the adversary is said to be successful if it can produce 
a valid signature to any message for which it has not asked for a signa¬ 
ture during its attack. Again, this refers to the ability to form signatures 
to possibly “nonsensical” messages as a breaking of the scheme. Yet, 
again, we see no way to have a general (i.e., application-independent) 
notion of “meaningful” messages (so that only forging signatures to 
them will be considered a breaking of the scheme). 


Definition 6.1. (secure signature schemes - a sketch): A chosen mes¬ 
sage attack is a process that, on input a verification-key, can obtain 
signatures (relative to the corresponding signing-key) to messages of 
its choice. Such an attack is said to succeed (in existential forgery) if it 
outputs a valid signature to a message for which it has NOT requested a 
signature during the attack. A signature scheme is secure (or unforge- 
able) if every feasible chosen message attack succeeds with at most 
negligible probability, where the probability is taken over the initial 
choice of the key-pair as well as over the adversary’s actions. 


We stress that plain RSA (alike plain versions of Rabin’s scheme (109|) 
and the DSS (jlj) ) is not secure under the above definition. However, it 
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may be secure if the message is “randomized” before RSA (or the other 
schemes) is applied. 


6.2 Constructions 

Secure message authentication schemes can be constructed using 
pseudorandom functions (|68,). Specifically, the key-generation algo¬ 
rithm consists of selecting a seed s € {0,1}" for such a function, 
denoted f s : {0,1}* —> {0, l} n , and the (only valid) tag of message x with 
respect to the key s is f s (x). As in the case of our private-key encryp¬ 
tion scheme, the proof of security of the current message authentication 
scheme consists of two steps: 


(1) Prove that an idealized version of the scheme, in which one 
uses a uniformly selected function F:{ 0,1}* —s>{0, l} n , rather 
than the pseudorandom function f s , is secure (i.e., unforge- 
able) . 

(2) Conclude that the real scheme (as presented above) is secure 
(because, otherwise one could distinguish a pseudorandom 
function from a truly random one). 


Note that the aforementioned message authentication scheme makes 
an “extensive use of pseudorandom functions” (i.e., the pseudorandom 
function is applied directly to the message, which requires a general¬ 
ized notion of pseudorandom functions (cf. Section 13.31 ) ). More efficient 
schemes may be obtained either based on a more restricted use of a 
pseudorandom function (cf., e.g., (fl7h) or based on other cryptographic 
primitives (cf., e.g., (93)). 

Constructing secure signature schemes seems more difficult than 
constructing message authentication schemes. Nevertheless, secure sig¬ 
nature schemes can be constructed based on any one-way function. 
Furthermore: 


Theorem 6.2. 


conditions are equivalent. 


(5M; \H2), see (£tL Sec. 6 . 4 )): The following three 
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(1) One-way functions exist. 

(2) Secure signature schemes exist. 

(3) Secure message authentication schemes exist. 

We stress that, unlike in the case of public-key encryption schemes, 

the construction of signature schemes (which may be viewed as a 
public-key analogue of message authentication) does not use a trapdoor 
property. 


How to construct secure signature schemes 

Three central paradigms used in the construction of secure signature 
schemes are the “refreshing” of the “effective” signing-key, the usage 
of an “authentication tree”, and the “hashing paradigm” (all to be 
discussed in the sequel). In addition to being used in the proof of 
Theorem 16.21 all three paradigms are also of independent interest. 


The refreshing paradigm. Introduced in (1821 ). the refreshing 
paradigm is aimed at limiting the potential dangers of chosen message 
attacks. This is achieved by signing the actual document using a newly 
(randomly) generated instance of the signature scheme, and authenti¬ 
cating (the verification-key of) this random instance with respect to the 
fixed public-key. That is, consider a basic signature scheme (G, S , V) 
used as follows. Suppose that the user U has generated a key-pair, 
(s,v) <— G( l n ), and has placed the verification-key v on a public-file. 
When a party asks U to sign some document a, the user U generates 
a new (“fresh”) key-pair, (s',v') <— G(l n ), signs v' using the origi¬ 
nal signing-key s, signs a using the new signing-key s ', and presents 
(S s (v'),v', S s '(a)) as a signature to a. An alleged signature, (/?i, v', fa), 
is verified by checking whether both V v (v 1 . j3\ ) = 1 and V v i(a. fa) = 1 
hold. Intuitively, the gain in terms of security is that a full-fledged cho¬ 
sen message attack cannot be launched on a fixed instance of (G, S, V ) 
(i.e., on the fixed verification-key that resides in the public-file and is 
known to the attacker). All that an attacker may obtain (via a chosen 
message attack on the new scheme) is signatures, relative to the origi¬ 
nal signing-key s of (G, S, V ), to random strings (distributed according 
to G(l n )) as well as additional signatures that are each relative to a 
random and independently distributed signing-key. 
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Authentication trees. The security benefits of the refreshing 
paradigm are increased when combining it with the use of authen¬ 
tication trees , as introduced in ([98). The idea is to use the pub¬ 
lic verification-key in order to authenticate several (e.g., two) fresh 
instances of the signature scheme, use each of these instances to authen¬ 
ticate several additional fresh instances, and so on. We obtain a tree of 
fresh instances of the basic signature scheme, where each internal node 
authenticates its children. We can now use the leaves of this tree in order 
to sign actual documents, where each leaf is used at most once. Thus, 
a signature to an actual document consists of (1) a signature to this 
document authenticated with respect to the verification-key associated 
with some leaf, and (2) a sequence of verification-keys associated with 
the nodes along the path from the root to this leaf, where each such 
verification-key is authenticated with respect to the verification-key of 
its parent. We stress that (by suitable implementation to be discussed 
below) each instance of the signature scheme is used to sign at most one 
string (i.e., a single sequence of verification-keys if the instance resides 
in an internal node, and an actual document if the instance resides in a 
leaf). Thus, it suffices to use a signature scheme that is secure as long 
as it is used to legitimately sign a single string. Such signa ture schemes, 
called one-time signature schemes and introduced in (1Q8|), are easier to 
construct than standard signature schemes, especially if one only wishes 
to sign strings that are significantly shorter than the signing-key (resp., 
than the verification-key). For example, using a one-way function /, we 
may let the signing-key consist of a sequence of n pairs of strings, let the 
corresponding verification-key consist of the corresponding sequence of 
images of f, and sign an n-bit long message by revealing the adequate 
pre-images o 


The hashing paradigm. Note, however, that in the aforementioned 
authentication-tree, the instances of the signature scheme (associated 
with internal nodes) are used to sign a pair of verification-keys. Thus, 


1 That, is, the signing-key consist of a sequence ((s9, s]),.... (s ( ;(, .sf)) G {0. 1 \ 2n , the cor¬ 
responding verification-key is (/(s®),/(s()),..., (/(s® ),/(sj,))), and the signature of the 
message tri ■ ■ • a n is (s^ 1 ,..., Sn n ). 
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we need a one-time signature scheme that can be used for signing mes¬ 
sages that are longer than the verification-key. Here is where the hashing 
paradigm comes into play. This paradigm refers to the common practice 
of signing documents via a two-stage process: First the actual document 
is hashed to a (relatively) short bit string, and next the basic signa¬ 
ture scheme is applied to the resulting string. This practice (as well 
as other usages of the hashing paradigm) is sound provided that the 
hashing function belongs to a family of collision-free hashing functions 
(i.e., loosely speaking, given a random hash function in the family, it 
is infeasible to find two different strings that are hashed by this func¬ 
tion to the same value; cf. 0). (A variant of the hashing paradigm 


uses the weaker notion of a family of Universal One- Way Hash Func¬ 


tions (cf. 
function 



103)), which in turn can be constructed using any one-way 


Implementation details. In order to implement the aforementioned 
(full-fledged) signature scheme one needs to store in (secure) memory 
all the instances of the basic (one-time) signature scheme that are gen¬ 
erated throughout the entire signing process (which refers to numerous 
documents). This can be done by extending the model so to allow for 
memory-dependent signature schemes. Alternatively, we note that all 
that we need to store are the random-coins used for generating each 
of these instances, and the former can be determined by a pseudoran¬ 
dom function (applied to the name of the corresponding vertex in the 
tree). Indeed, the seed of this pseudorandom function will be part of 
the signing-key of the resulting (full-fledged) signature scheme. 

6.3 Public-key infrastructure 

The standard use of public-key encryption schemes (resp., signature 
schemes) in real-life communication requires a mechanism for provid¬ 
ing the sender (resp., signature verifier) with the receiver’s authentic 
encryption-key (resp., signer’s authentic verification-key). Specifically, 
this problem arises in large-scale systems, where typically the sender 
(resp., verifier) does not have a local record of the receiver’s encryption- 
key (resp., signer’s verification-key), and so must obtain this key in a 
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“reliable” way (i.e., typically, certified by some trusted authority). In 
most theoretical works, one assumes that the keys are posted on and 
can be retrieved from a public-file that is maintained by a trusted party 
(which makes sure that each user can post only keys bearing its own 
identity). In practice, maintaining such a public-file is a major problem, 
and mechanisms that implement this abstraction are typically referred 
to by the generic term “public-key infrastructure (PKI)”. For a discus¬ 
sion of the practical problems regarding PKI deployment see, e.g., ([971 , 
Section 13). 




7 


General Cryptographic Protocols 


The design of secure protocols that implement arbitrary desired func¬ 
tionalities is a major part of modern cryptography. Taking the opposite 
perspective, the design of any cryptographic scheme may be viewed as 
the design of a secure protocol for implementing a suitable functional¬ 
ity. Still, we believe that it makes sense to differentiate between basic 
cryptographic primitives (which involve little interaction) like encryp¬ 
tion and signature schemes on one hand, and general cryptographic 
protocols on the other hand. 

We survey general results concerning secure multi -party computa¬ 
tions, where the two-party case is an important special case. In a nut¬ 
shell, these results assert that one can construct protocols for securely 
computing any desirable multi-party functionality. Indeed, what is 
striking about these results is their generality, and we believe that the 
wonder is not diminished by the (various alternative) conditions under 
which these results hold. 

Our focus on the general study of secure multi-party computation 
(rather than on protocols for solving specific problems) is natural in 
the context of the theoretical treatment of the subject matter. We wish 
to highlight the importance of this general study to practice. Firstly, 
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this study clarifies fundamental issues regarding security in a multi¬ 
party environment. Secondly, it draws the lines between what is possible 
in principle and what is not. Thirdly, it develops general techniques 
for designing secure protocols. And last, sometimes, it may even yield 
schemes (or modules) that may be incorporated in practical systems. 




IDEAL MODEL 


Fig. 7.1 Secure protocols emulate a trusted party - an illustration. 


A general framework for casting (m-party) cryptographic (protocol) 
problems consists of specifying a random procesqj that maps m inputs 
to m outputs. The inputs to the process are to be thought of as the local 
inputs of m parties, and the m outputs are their corresponding (desired) 
local outputs. The random process describes the desired functionality. 
That is, if the m parties were to trust each other (or trust some external 
party), then they could each send their local input to the trusted party, 
who would compute the outcome of the process and send to each party 
the corresponding output. A pivotal question in the area of crypto¬ 
graphic protocols is to what extent can this (imaginary) trusted party 
be “emulated” by the mutually distrustful parties themselves. 


1 That is, we consider the secure evaluation of randomized functionalities, rather than 
“only” the secure evaluation of functions. Specifically, we consider an arbitrary (ran¬ 
domized) process F that on input (xi first selects at random (depending only 
on i c = f \%i\) an m-ary function /, and then outputs the m-tuple f(x i, ...,a? m ) = 

...,fm(x 1 , In other words, F(x i, ...,£ m ) = F'(r,x i, ...,cc m ), where 

r is uniformly selected in {0,1}^ (with f — poly(£)), and F r is a function mapping (m+1)- 
long sequences to m-long sequences. 
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The results surveyed below describe a variety of models in which 
such an “emulation” is possible. The models vary by the underlying 
assumptions regarding the communication channels, numerous para¬ 
meters relating to the extent of adversarial behavior, and the desired 
level of emulation of the trusted party (i.e., level of “security”). 


Organization: Section 17. ll nrovides a rather comprehensive survey of 
the various definitions used in the area of secure multi-party computa¬ 
tion, whereas Section T7.2I similarly surveys the known results. However, 
some readers may prefer to first consider one concrete case of the def¬ 
initional approach, as provided in Section 17.1.21 and proceed directly 
to see some constructions. Indeed, a few constructions are sketched in 
Section 1731 All the above refers to the security of stand-alone exe¬ 
cutions, and the preservation of security in an environment in which 
many executions of many protocols are being attacked is considered in 
Section 17.41 


7.1 The definitional approach and some models 


Before describing the aforementioned results, we further discuss the 
notion of “emulating a trusted party”, which underlies the definitional 
approach to secure multi-party computation (as initiated and developed 
in (73; IOC; 0; 0; EB; Ed))- The approach can be traced back to the 
definition of zero-knowledge (cf. (81)), and even to the definition of 
secure encryption (cf. (64), rephrasing (80)). The underlying paradigm 
(called the simulation paradigm (cf. Section 14.11) ) is that a scheme is 
secure if whatever a feasible adversary can obtain after attacking it, is 
also feasibly attainable “from scratch”. In the case of zero-knowledge 
this amounts to saying that whatever a (feasible) verifier can obtain 
after interacting with the prover on a prescribed valid assertion, can be 
(feasibly) computed from the assertion itself. In the case of multi-party 
computation we compare the effect of adversaries that participate in 
the execution of the actual protocol to the effect of adversaries that 
participate in an imaginary execution of a trivial (ideal) protocol for 
computing the desired functionality with the help of a trusted party. If 
whatever the adversaries can feasibly obtain in the former real setting 
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can also be feasibly obtained in the latter ideal setting then the protocol 
“emulates the ideal setting” (i.e., “emulates a trusted party”), and so 
is deemed secure. This basic approach can be applied in a variety of 
models, and is used to define the goals of security in these models o We 
first discuss some of the parameters used in defining various models, 
and next demonstrate the application of this approach in two important 
models. For further details, see (I36i l or (1671 Sec. 7.2 and 7.5.1). 


7.1.1 Some parameters used in defining security models 

The following parameters are described in terms of the actual (or real) 
computation. In some cases, the corresponding definition of security is 
obtained by imposing some restrictions or provisions on the ideal model. 
For example, in the case of two-party computation (see below), secure 
computation is possible only if premature termination is not consid¬ 
ered a breach of security. In that case, the suitable security definition 
is obtained (via the simulation paradigm) by allowing (an analogue 
of) premature termination in the ideal model. In all cases, the desired 
notion of security is defined by requiring that for any adequate adver¬ 
sary in the real model, there exist a corresponding adversary in the 
corresponding ideal model that obtains essentially the same impact (as 
the real-model adversary). 


The communication channels: The parameters of the model 
include questions like whether or not the channels may be 
tapped by an adversary, whether or not they are tamper-free, 
and questions referring to the network behavior (in the case of 
multi-party protocols). 


2 A few technical comments are in place. Firstly, we assume that the inputs of all parties are 
of the same length. We comment that as long as the lengths of the inputs are polynomially 
related, the above convention can be enforced by padding. On the other hand, some length 
restriction is essential for the security results, because in general it is impossible to hide 
all information regarding the length of the inputs to a protocol. Secondly, we assume 
that the desired functionality is computable in probabilistic polynomial-time, because we 
wish the secure protocol to run in probabilistic polynomial-time (and a protocol cannot 
be more efficient than the corresponding centralized algorithm). Clearly, the results can 
be extended to functionalities that are computable within any given (time-constructible) 
time bound, using adequate padding. 
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Wire-tapping versus the private-channel model: The standard 
assumption in cryptography is that the adversary may tap all 
communication channels (between honest parties). In contrast, 
one may postulate that the adversary cannot obtain messages 
sent between a pair of honest parties, yielding the so-called 
private-channel model (cf. (1251; I42l)). The latter postulate may 
be justified in some settings. Furthermore, it may be viewed as a 
useful abstraction that provides a clean model for the study and 
development of secure protocols. In this respect, it is important 
to mention that, in a variety of settings of the other parameters, 
private channels can be easily emulated by ordinary “tapped 
channels”. 

Broadcast channel: In the multi-party context, one may postu¬ 
late the existence of a broadcast channel (cf. ( 1101 )). and the 
motivation and justifications are as in the case of the private- 
channel model. 

The tamper-free assumption: The standard assumption in the 
area is that the adversary cannot modify, duplicate, or gener¬ 
ate messages sent over the communication channels (between 
honest parties). Again, this assumption can be justified in some 
settings and can be emulated in others (cf., (18; 341)1. 

Network behavior: Most works in the area assume that com¬ 
munication is synchronous and that point-to-point channels 
exist between every pair of processors (i.e., a complete net¬ 
work). However, one may also consider asynchronous communi¬ 
cation (cf. (|23j)) and arbitrary networks of point-to-point chan¬ 
nels (cf. dim 

Set-up assumptions: Unless stated differently, we make no set-up 
assumptions (except for the obvious assumption that all par¬ 
ties have identical copies of the protocol’s program). How¬ 
ever, in some cases it is assumed that each party knows a 
verification-key corresponding to each of the other parties (or 
that a public-key infrastructure is available). Another assump¬ 
tion, made more rarely, is that all parties have access to some 
common (trusted) random string. 
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Computational limitations: Typically, we consider computation¬ 
ally-bounded adversaries (e.g., probabilistic polynomial-time 
adversaries). However, the private-channel model allows for 
the (meaningful) consideration of computationally-unbounded 
adversaries. 

We stress that, also in the case of computationally-unbounded 
adversaries, security should be defined by requiring that for 
every real adversary, whatever the adversary can compute after 
participating in the execution of the actual protocol is com¬ 
putable within comparable time by an imaginary adversary par¬ 
ticipating in an imaginary execution of the trivial ideal proto¬ 
col (for computing the desired functionality with the help of 
a trusted party). That is, although no computational restric¬ 
tions are made on the real-model adversary, it is required that 
the ideal-model adversary that obtains the same impact does 
so within comparable time (i.e., within time that is polyno- 
mially related to the running time of the real-model adver¬ 
sary being simulated). Thus, any construction proven secure in 
the computationally-unbounded adversary model is (trivially) 
secure with respect to computationally-bounded adversaries. 

Restricted adversarial behavior: The parameters of the model 
include questions like whether or not the adversary is “adap¬ 
tive” and “active” (where these terms are discussed next). 
Adaptive versus non-adaptive: The most general type of an 
adversary considered in the literature is one that may corrupt 
parties to the protocol while the execution goes on, and does so 
based on partial information it has gathered so far (cf., (371)). 
A somewhat more restricted model, which seems adequate in 
many settings, postulates that the set of dishonest parties is 
fixed (arbitrarily) before the execution starts (but this set is, 
of course, not known to the honest parties). The latter model 
is called non-adaptive as opposed to the adaptive adversary 
discussed first. Although the adaptive model is stronger, the 
author believes that the non-adaptive model provides a reason¬ 
able level of security in many applications. 
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Active versus passive: An orthogonal parameter of restriction 
refers to whether a dishonest party takes active steps to dis¬ 
rupt the execution of the protocol (i.e., sends messages that 
differ from those specified by the protocol), or merely gath¬ 
ers information (which it may latter share with the other dis¬ 
honest parties). The latter adversary has been given a variety 
of names such as semi-honest , passive , and honest-but-curious. 
This restricted model may be justified in certain settings, and 
certainly provides a useful methodological locus (cf., (75; 74; 63) 
and Section 17.31) . Below we refer to the adversary of the unre¬ 
stricted model as to active ; another commonly used name is 
malicious. 

Restricted notions of security: One important example is the will¬ 
ingness to tolerate “unfair” protocols in which the execution 
can be suspended (at any time) by a dishonest party, provided 
that it is detected doing so. We stress that in case the execu¬ 
tion is suspended, the dishonest party does not obtain more 
information than it could have obtained when not suspending 
the execution. (What may happen is that the honest parties will 
not obtain their desired outputs, but rather will detect that the 
execution was suspended.) We stress that the motivation to this 
restricted model is the impossibility of obtaining general secure 
two-party computation in the unrestricted model. 

Upper bounds on the number of dishonest parties: In some 
models, secure multi-party computation is possible only if a 
majority of the parties is honest (cf., (25; 44)). Sometimes even 
a special majority (e.g., 2/3) is required. General “(resilient) 
adversarial-structures” have been considered too (cf. (jsol)). 

Mobile adversary: In most works, once a party is said to be dishon¬ 
est it remains so throughout the execution. More generally, one 
may consider transient adversarial behavior (e.g., an adversary 
seizes control of some site and later withdraws from it). This 
model, introduced in (106), allows to construct protocols that 
remain secure even in case the adversary may seize control of 
all sites during the execution (but never control concurrently, 
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say, more than 10% of the sites). We comment that schemes 
secure in this model were later termed “proactive” (cf., (139)). 


7.1.2 Example: Multi-party protocols with honest majority 

Here we consider an active, non-adaptive, computationally-bounded 
adversary, and do not assume the existence of private channels. Our 
aim is to define multi-party protocols that remain secure provided that 
the honest parties are in majority. (The reason for requiring a honest 
majority will be discussed at the end of this subsection.) 

Consider any multi-party protocol. We first observe that each party 
may change its local input before even entering the execution of the 
protocol. However, this is unavoidable also when the parties utilize a 
trusted party. Consequently, such an effect of the adversary on the 
real execution (i.e., modification of its own input prior to entering the 
actual execution) is not considered a breach of security. In general, 
whatever cannot be avoided when the parties utilize a trusted party, 
is not considered a breach of security. We wish secure protocols (in 
the real model) to suffer only from whatever is unavoidable also when 
the parties utilize a trusted party. Thus, the basic paradigm underlying 
the definitions of secure multi-party computations amounts to requiring 
that the only situations that may occur in the real execution of a secure 
protocol are those that can also occur in a corresponding ideal model 
(where the parties may employ a trusted party). In other words, the 
“effective malfunctioning” of parties in secure protocols is restricted to 
what is postulated in the corresponding ideal model. 

When defining secure multi-party protocols with honest majority, 
we need to pin-point what cannot be avoided in the ideal model (i.e., 
when the parties utilize a trusted party). This is easy, because the ideal 
model is very simple. Since we are interested in executions in which the 
majority of parties are honest, we consider an ideal model in which any 
minority group (of the parties) may collude as follows: 

(1) Firstly this dishonest minority shares its original inputs and 
decides together on replaced inputs to be sent to the trusted 
party. (The other parties send their respective original inputs 
to the trusted party.) 
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(2) Upon receiving inputs from all parties, the trusted party 
determines the corresponding outputs and sends them to the 
corresponding parties. (We stress that the information sent 
between the honest parties and the trusted party is not seen 
by the dishonest colluding minority.) 

(3) Upon receiving the output-message from the trusted party, 
each honest party outputs it locally, whereas the dishonest 
colluding minority may determine their outputs based on all 
they know (i.e., their initial inputs and their received out¬ 
puts). 

Note that the above behavior of the minority group is unavoidable in 
any execution of any protocol (even in presence of trusted parties). 
This is the reason that the ideal model was defined as above. Now, 
a secure multi-party computation with honest majority is required to 
emulate this ideal model. That is, the effect of any feasible adversary 
that controls a minority of the parties in a real execution of the actual 
protocol, can be essentially simulated by a (different) feasible adversary 
that controls the corresponding parties in the ideal model. That is: 


Definition 7.1. (secure protocols - a sketch): Let / be an m -ary func¬ 
tionality and II be an m-party protocol operating in the real model. 

• For a real-model adversary A. controlling some minority of 
the parties (and tapping all communication channels), and 
an m-sequence x, we denote by REALn,/i(T) the sequence of 
m outputs resulting from the execution of II on input x under 
attack of the adversary A. 

• For an ideal-model adversary A ', controlling some minority of 
the parties, and an m-sequence x, we denote by iDEALy^^x) 
the sequence of m outputs resulting from the ideal process 
described above, on input x under attack of the adversary 
A'. 


We say that II securely implements / with honest majority if for every 
feasible real-model adversary A. controlling some minority of the par- 
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ties, there exists a feasible ideal-model adversary A !, controlling the 
same parties, so that the probability ensembles {REALn,A(^)}x and 
{iDEALjyi/^)}^ are computationally indistinguishable (as in Foot¬ 
note O . 

Thus, security means that the effect of each minority group in a real 
execution of a secure protocol is “essentially restricted” to replacing its 
own local inputs (independently of the local inputs of the majority 
parties) before the protocol starts, and replacing its own local outputs 
(depending only on its local inputs and outputs) after the protocol 
terminates. (We stress that in the real execution the minority parties 
do obtain additional pieces of information; yet in a secure protocol they 
gain nothing from these additional pieces of information, because they 
can actually reproduce those by themselves.) 

The fact that Definition 17. II refers to a model without private chan¬ 
nels is due to the fact that our (sketchy) definition of the real-model 
adversary allowed it to tap the channels, which in turn effects the 
set of possible ensembles {REALn,A(T)}x- When defining security in 
the private-channel model, the real-model adversary is not allowed to 
tap channels between honest parties, and this again effects the pos¬ 
sible ensembles {REALn,A(T)}x- On the other hand, when we wish to 
define security with respect to passive adversaries, both the scope of 
the real-model adversaries and the scope of the ideal-model adversaries 
changes. In the real-model execution, all parties follow the protocol but 
the adversary may alter the output of the dishonest parties arbitrarily 
depending on all their intermediate internal states (during the execu¬ 
tion). In the corresponding ideal-model, the adversary is not allowed 
to modify the inputs of dishonest parties (in Step 1), but is allowed to 
modify their outputs (in Step 3). 

We comment that a definition analogous to Definition 17.11 can be 
presented also in case the dishonest parties are not in minority. In fact, 
such a definition seems more natural, but the problem is that such a 
definition cannot be satisfied. That is, most natural functionalities do 
not have a protocol for computing them securely in case at least half of 
the parties are dishonest and employ an adequate adversarial strategy. 
This follows from an impossibility result regarding two-party computa- 
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tion, which essentially asserts that there is no way to prevent a party 
from prematurely suspending the execution (1461 ). On the other hand, 
secure multi-party computation with dishonest majority is possible if 
premature suspension of the execution is not considered a breach of 
security (cf. Section f7. 1.51) . 


7.1.3 Another example: Two-party protocols allowing abort 

In light of the last paragraph, we now consider multi-party computa¬ 
tions in which premature suspension of the execution is not considered 
a breach of security. For concreteness, we focus here on the special case 
of two-party computations^ 

Intuitively, in any two-party protocol, each party may suspend the 
execution at any point in time, and furthermore it may do so as soon 
as it learns the desired output. Thus, in case the output of each parties 
depends on both inputs, it is always possible for one of the parties to 
obtain the desired output while preventing the other party from fully 
determining its own output. The same phenomenon occurs even in case 
the two parties just wish to generate a common random value. Thus, 
when considering active adversaries in the two-party setting, we do 
not consider such premature suspension of the execution a breach of 
security. Consequently, we consider an ideal model where each of the 
two parties may “shut-down” the trusted (third) party at any point 
in time. In particular, this may happen after the trusted party has 
supplied the outcome of the computation to one party but before it 
has supplied it to the other. That is, an execution in the ideal model 
proceeds as follows: 


(1) Each party sends its input to the trusted party, where the 
dishonest party may replace its input or send no input at all 
(which can be treated as sending a default value). 

(2) Upon receiving inputs from both parties, the trusted party 
determines the corresponding outputs, and sends the first 
output to the first party. 


3 As in Section 17.1.21 we consider a non-adaptive, active, computationally-bounded adver- 
sary. 
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(3) In case the first party is dishonest, it may instruct the trusted 
party to halt, otherwise it always instructs the trusted party 
to proceed. If instructed to proceed, the trusted party sends 
the second output to the second party. 

(4) Upon receiving the output-message from the trusted party, 
the honest party outputs it locally, whereas the dishonest 
party may determine its output based on all it knows (i.e., 
its initial input and its received output). 


A secure two-party computation allowing abort is required to emulate this 
ideal model. That is, as in Definition 17.11 security is defined by requir¬ 
ing that for every feasible real-model adversary A, there exists a fea¬ 
sible ideal-model adversary A !, controlling the same party, so that the 
probability ensembles representing the corresponding (real and ideal) 
executions are computationally indistinguishable. This means that each 
party’s “effective malfunctioning” in a secure protocol is restricted to 
supplying an initial input of its choice and aborting the computation 
at any point in time. (Needless to say, the choice of the initial input of 
each party may not depend on the input of the other party.) 

We mention that an alternative way of dealing with the problem of 
premature suspension of execution (i.e., abort) is to restrict our atten¬ 
tion to single-output functionalities; that is, functionalities in which only 
one party is supposed to obtain an output. The definition of secure com¬ 
putation of such functionalities can be made identical to Definition 17.11 
with the exception that no restriction is made on the set of dishonest 
parties (and in particular one may consider a single dishonest party in 
the case of two-party protocols). For further details, see (j67l . Sec. 7.2.3). 


7.2 Some known results 


We next list some of the models for which general secure multi-party 
computation is known to be attainable (i.e., models in which one can 
construct secure multi-party protocols for computing any desired func¬ 
tionality). We mention that the first results of this type were obtained 


by Goldreich, Micali, Wigderson and Yao (|75|; 124; M). 


u-i 
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Assuming the existence of enhance (0 trapdoor permutations , 
secure multi-pa rty c omputation is possible in the following 
models (cf. (75; 124; El) and details in (63; 67)): 

(1) Passive adversary, for any number of dishonest par¬ 
ties (cf. (67, Sec. 7.3)). 

(2) Active adversary that may control only a minority of 
the parties (cf. (67, Sec. 7.5.4)). 

(3) Active adversary, for any number of bad parties, pro¬ 
vided that suspension of execution is not consid¬ 
ered a violation of security (i.e., as discussed in Sec¬ 
tion EL3|). (See (67, Sec. 7.4 and 7.5.5).) 

In all these cases, the adversary is computationally-bounded 
and non-adaptive. On the other hand, the adversary may tap 
the communication lines between honest parties (i.e., we do 
not assume “private channels” here). The results for active 
adversaries assume a broadcast channel. Indeed, the latter 
can be implemented (while tolerating any number of bad 
parties) using a signature scheme and assuming a public-key 
infrastructure (or that each party knows the verification-key 
corresponding to each of the other parties). 

Making no computational assumptions and allowing 
computationally-unbounded adversaries, but assuming pri¬ 
vate channels , secure multi-party computation is possible in 
the following models (cf. (251; 142)): 

(1) Passive adversary that may control only a minority 
of the parties. 

(2) Active adversary that may control only less than one 
third of the parties H 

In both cases the adversary may be adaptive (cf. (1251 :137144. 
Secure multi-party computation is possible against an active, 
adaptive and mobile adversary that may control a small con¬ 
stant fraction of the parties at any point in time (106i). 


4 See Footnote [5] 

5 Fault-tolerance can be increased to a regular minority if a broadcast channel exists (|llO)i . 
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This result makes no computational assumptions, allows 
computationally-unbounded adversaries, but assumes pri¬ 
vate channels. 

• Assuming the existence of enhanced trapdoor permutations , 
secure multi-party computation is possible in a model 
allowing an active and adaptive computationally-bounded 
adversary that may control only less than one third of the 
parties (37; 48). We stress that this result does not assume 
“private channels”. 

Results for asynchronous communication and arbitrary networks of 
point-to-point channels were presented in ( 231 ; 26) and ([51), respec¬ 
tively. 

Note that the implementation of a broadcast channel can be 
cast as a cryptographic protocol problem (i.e., for the functionality 
(v,X, ...,A) i—> (v,v, where A denotes the empty string). Thus, 

it is not surprising that the results regarding active adversaries either 
assume the existence of such a channel or require a setting in which 
the latter can be implemented. 


Secure reactive computation: All the above results (easily) extend 
to a reactive model of computation in which each party interacts with a 
high-level process (or application). The high-level process supplies each 
party with a sequence of inputs, one at a time, and expect to receive 
corresponding outputs from the parties. That is, a reactive system goes 
through (a possibly unbounded number of) iterations of the following 
type: 


• Parties are given inputs for the current iteration. 

• Depending on the current inputs, the parties are supposed 
to compute outputs for the current iteration. That is, the 
outputs in iteration j are determined by the inputs of the 
jth iteration. 

A more general formulation allows the outputs of each iteration to 
depend also on a global state, which is possibly updated in each itera¬ 
tion. The global state may include all inputs and outputs of previous 
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iterations, and may only be partially known to individual parties. (In 
a secure reactive computation such a global state may be maintained 
by all parties in a “secret sharing” manner.) For further discussion, 
see (67, Sec. 7.7.1). 


Efficiency considerations: One important efficiency measure 
regarding protocols is the number of communication rounds in their 
execution. The results mentioned above were originally obtained using 
protocols that use an unbounded number of rounds. In some cases, sub¬ 
sequent works obtained secure constant-round protocols: for example, 
in the case of multi-party computations with honest majority (cf. (15J)) 
and in the case of two-party computations allowing abort (cf. ([94)). 
Other important efficiency considerations include the total number of 
bits sent in the execution of a protocol, and the local computation time. 
The (communication and computation) complexities of the protocols 
establishing the above results are related to the computational com¬ 
plexity of the computation, but alternative relations (e.g., where the 
complexities of the secure protocols are related to the (insecure ) com - 
munication complexity of the computation) may be possible (cf. (102)). 


Theory versus practice (or general versus specific): This 
primer is focused on presenting general notions and general feasibil¬ 
ity results. Needless to say, practical solutions to specific problems 


(e.g., voting (84), secure payment systems (11 a ), and threshold crypto¬ 
systems (1601 )) are typically derived by specific constructions (and not by 
applying general results of the abovementioned type). Still, the (above- 
mentioned) general results are of great importance to practice because 
they characterize a wide class of security problems that are solvable 
in principle, and provide techniques that may be useful also towards 
constructing reasonable solutions to specific problems. 


7.3 Construction paradigms and two simple protocols 

We briefly sketch a couple of paradigms used in the construction of 
secure multi-party protocols. We focus on the construction of secure 
protocols for the model of computationally-bounded and non-adaptive 
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adversaries _[ 75:: 112 3: 74). These constructions proceed in two steps (see 
details in (63 HgtI'I ) First a secure protocol is presented for the model 
of passive adversaries (for any number of dishonest parties), and next 
such a protocol is “compiled” into a protocol that is secure in one of 
the two models of active adversaries (i.e., either in a model allowing 
the adversary to control only a minority of the parties or in a model 
in which premature suspension of the execution is not considered a 
violation of security). These two steps are presented in the following 
two corresponding subsections, in which we also present two relatively 
simple protocols for two specific tasks, which are used extensively in 
the general protocols. 

Recall that in the model of passive adversaries, all parties follow 
the prescribed protocol, but at termination the adversary may alter 
the outputs of the dishonest parties depending on all their intermediate 
internal states (during the execution). Below, we refer to protocols that 
are secure in the model of passive (resp., active) adversaries by the term 
passively-secure (resp., actively-secure). 


7.3.1 Passively-secure computation with shares 

For any m > 2, suppose that m parties, each having a private input, 
wish to obtain the value of a predetermined m-argument function 
evaluated at their sequence of inputs. Below, we outline a passively- 
secure protocol for achieving this goal. We mention that the design 
of passively-secure multi-party protocol for any functionality (allowing 
different outputs to different parties as well as handling also random¬ 
ized computations) reduces easily to the aforementioned task. 

We assume that the parties hold a circuit for computing the value 
of the function on inputs of the adequate length, and that the circuit 
contains only and and not gates. The key idea is to have each party 
“secretly share” its input with everybody else, and “secretly transform” 
shares of the input wires of the circuit into shares of the output wires 
of the circuit, thus obtaining shares of the outputs (which allows for 
the reconstruction of the actual outputs). The value of each wire in the 
circuit is shared in a way such that all shares yield the value, whereas 
lacking even one of the shares keeps the value totally undetermined. 









7.3. Construction paradigms and two simple protocols 101 


That is, we use a simple secret sharing scheme (cf. (11171 )1 such that a 
bit b is shared by a random sequence of m bits that sum-up to b mod 
2. First, each party shares each of its input bits with all parties (by 
secretly sending each party a random value and setting its own share 
accordingly). Next, all parties jointly scan the circuit from its input 
wires to the output wires, processing each gate as follows: 


• When encountering a gate, the parties already hold shares of 
the values of the wires entering the gate, and their aim is to 
obtain shares of the value of the wires exiting the gate. 

• For a not-gate this is easy: the first party just flips the value 
of its share, and all other parties maintain their shares. 

• Since an and-gate corresponds to multiplication modulo 2, 
the parties need to securely compute the following random¬ 
ized functionality (in which the x^s denote shares of one 
entry-wire, the yi s denote shares of the second entry-wire, 
the Zi s denote shares of the exit-wire, and the shares indexed 
by i belongs to Party i ): 

((xi,yi),...,(x m ,y m )) (zi,...,z m ) (7.1) 

where E™ i * = (E™ i *i) ■ (E™ i Vi)- (7-2) 

That is, the Zi s are random subject to Eq. m- 

Finally, the parties send their shares of each circuit-output wire to the 
designated party, which reconstructs the value of the corresponding bit. 
Thus, the parties have propagated shares of the input wires into shares 
of the output wires, by repeatedly conducting privately-secure compu¬ 
tation of the m -ary functionality of Eq. That is, securely 

evaluating the entire (arbitrary) circuit “reduces” to securely conduct¬ 
ing a specific (very simple) multi-party computation. But things get 
even simpler: the key observation is that 

( m \ / m \ m 

= ^2 x iVi+ Y {.XiVj + XjVi) (7-3) 

2—1 / \ 2=1 / 2=1 l<i<j<m 

Thus, the m -ary functionality of Eq. (17.1(1 & (17.21) can be computed as 
follows (where all arithmetic operations are mod 2): 
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(1) 

( 2 ) 


Each Party i locally computes z t , t = f XiUi. 

Next, each pair of parties (i.e., Parties i and j) securely 
compute random shares of Xiyj + yiXj. That is, Parties i 
and j (holding ( Xi,yi ) and ( Xj,yj ), respectively), need to 
securely compute the randomized two-party functionality 
(( Xi,yi ), ( Xj,yj )) i—> (zij, Zj'i), where the z’s are random sub¬ 
ject to Zij + Zj t i = x^j + yiXj. Equivalently, Party j uni¬ 
formly selects Zj i G {0,1}, and Parties i and j securely com¬ 
pute the deterministic functionality ( (x {, yi ), (xj , yj. zjj )) i—> 
(zjj + x^j + yiXj, A), where A denotes the empty string. 
The latter simple two-party computation can be securely 
implemented using a l-out-of-4 Oblivious Transfer (cf. ([T9j) 
and (I671 . Sec. 7.3.3)), which in turn can be implemented using 
enhanced trapdoor permutations (see below). Loosely speak¬ 
ing, a 1-out-of-A: Oblivious Transfer is a protocol enabling one 
party to obtain one of k secrets held by another party, with¬ 
out the second party learning which secret was obtained by 
the first party. That is, we refer to the two-party functionality 


(i,(si,...,s fc )) i-> (sj,A). (7.4) 

Note that any function / : [k] x {0,1}* —► {0,1}* can 
be privately-computed by invoking a 1-out-of-fc Oblivious 
Transfer on inputs i and (f(l,y),... 1 f(k,y)), where i (resp., 
y) is the initial input of the first (resp., second) party. 

(3) Finally, for every i = 1,..., m, summing-up all the Zi j’s yields 
the desired share of Party i. 


The above construction is analogous to a construction that was briefly 
described in (174 ). A detailed description and full proofs appear in (63; 
0 ). 

We mention that an analogous construction has been subsequently 
used in the private channel model and withstands computationally 
unbounded active (resp., passive) adversaries that control less than 
one third (resp., a minority) of the parties ([251 ). The basic idea is to 
use a more sophisticated secret sharing scheme; specifically, via a low 
degree polynomial (117)- That is, the Boolean circuit is viewed 


as an 
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arithmetic circuit over a finite field having more than m elements, and 
a secret element s of the field is shared by selecting uniformly a polyno¬ 
mial of degree d = [(m — l)/3j (resp., degree d = [(m — l)/2j) having 
a free-ternr equal to s, and handing each party the value of this poly¬ 
nomial evaluated at a different (fixed) point (e.g., party i is given the 
value at point i). Addition is emulated by (local) point-wise addition 
of the (secret sharing) polynomials representing the two inputs (using 
the fact that for polynomials p and q, and any field element e (and 
in particular e = 0,1, it holds that p(e) + q(e) = (p + q)(e)). 

The emulation of multiplication is more involved and requires interac¬ 
tion (because the product of polynomials yields a polynomial of higher 
degree, and thus the polynomial representing the output cannot be the 
product of the polynomials representing the two inputs). Indeed, the 
aim of the interaction is to turn the shares of the product polynomial 
into shares of a degree d polynomial that has the same free-term as the 
product polynomial (which is of degree 2d). This can be done using the 
fact that the coefficients of a polynomial are a linear combination of 
its values at sufficiently many arguments (and the other way around), 
and the fact that one can privately-compute any linear combination (of 
secret values). For details see (1251: l6ll ). 


A passively-secure 1-out-of-A; Oblivious Transfer. Using a col¬ 
lection of enhanced trapdoor permutations, {f a : D a —> D a } ae y, 
we outline a passively-secure implementation of the functionality of 
Eq. (17.41) . The implementation originates in ( Jj3 ) (and a full description 
is provided in (67, Sec. 7.3.2)). 


Inputs'. The sender has input (cr^ero, ...,cxfc) £ {0, l} fc , the receiver has 
input i 6 {1, 2,..., k}. 

Step SI: The sender selects at random a permutation f a along with a 
corresponding trapdoor, denoted t, and sends the permutation 
f a (i.e., its index a) to the receiver. 

Step Rl: The receiver uniformly and independently selects 
Xi,...,x k e D a , sets m = f a (xi) and y 3 = x 3 for every 
j i, and sends (yi,y 2 , ••• ,yu ) to the sender. 
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Thus, the receiver knows = x ii but cannot predict 

b(f~ 1 (yj)) for any j / i. Of course, the last assertion presumes 
that the receiver follows the protocol (i.e., is senri-honest). 

Step S2: Upon receiving (yi, U2, •••, Vk), using the inverting-with- 
trapdoor algorithm and the trapdoor t, the sender computes 
Zj = f°r every j £ {1, It sends the £;-tuple 

(ui © b(zi),a 2 © b(z 2 ),cTfe © b{zk)) to the receiver. 

Step R2: Upon receiving (ci, C 2 ,Cfc), the receiver locally outputs 
Ci © b(xi). 


We first observe that the above protocol correctly computes l-out-of-/c 
Oblivious Transfer; that is, the receiver’s local output (i.e., Cj © b(xi )) 
indeed equals (dj © b(f~ 1 (f a (xi)))) © b(xi) = Oi . Next, we offer some 
intuition as to why the above protocol constitutes a privately-secure 
implementation of l-out-of-/c Oblivious Transfer. Intuitively, the sender 
gets no information from the execution because, for any possible value 
of i, the sender sees the same distribution; specifically, a sequence of k 
uniformly and independently distributed elements of D a . (Indeed, the 
key observation is that applying f a to a uniformly distributed element 
of D a yields a uniformly distributed element of D a .) Intuitively, the 
receiver gains no computational knowledge from the execution because, 
for j 7 ^ i, the only information that the receiver has regarding aj is 


© b(f a 1 (xj))), where Xj is uniformly distributed 


the triplet (a,Xj,<jj 
in D a , and from this information it is infeasible to predict ctj better 
than by a random guess. The latter intuition presumes that sampling 
D a is trivial (i.e., that there is an easily computable correspondence 
between the coins used for sampling and the resulting sample), whereas 
in general the coins used for sampling may be hard to compute from the 
corresponding outcome (which is the reason that an enhanced hardness 
assumption is used in the general analysis of the the above protocol). 
(See (1671 . Sec. 7.3.2) for a detailed proof of security.) 


7.3.2 Compilation of passively-secure protocols into actively- 
secure ones 

We show how to transform any passively-secure protocol into a corre¬ 
sponding actively-secure protocol. The communication model in both 
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protocols consists of a single broadcast channel. Note that the messages 
of the original protocol may be assumed to be sent over a broadcast 
channel, because the adversary may see them anyhow (by tapping the 
point-to-point channels), and because a broadcast channel is trivially 
implementable in the case of passive adversaries. As for the resulting 
actively-secure protocol, the broadcast channel it uses can be imple¬ 
mented via an (authenticated) Byzantine Agreement protocol (152i; 1951), 
thus providing an emulation of this model on the standard point-to- 
point model (in which a broadcast channel does not exist). We men¬ 
tion that authenticated Byzantine Agreement is typically implemented 
using a signature scheme (and assuming that each party knows the 
verification-key corresponding to each of the other parties). 

Turning to the transformation itself, the main idea is to use zero- 
knowledge proofs (as described in Section 14.31) in order to force parties 
to behave in a way that is consistent with the (passively-secure) pro¬ 
tocol. Actually, we need to confine each party to a unique consistent 
behavior (i.e., according to some fixed local input and a sequence of coin 
tosses), and to guarantee that a party cannot fix its input (and/or its 
coins) in a way that depends on the inputs of honest parties. Thus, some 
preliminary steps have to be taken before the step-by-step emulation 
of the original protocol may start. Specifically, the compiled protocol 
(which like the original protocol is executed over a broadcast channel) 
proceeds as follows: 


(1) Committing to the local input: Prior to the emulation of the 
original protocol, each party commits to its input (using 
a commitment scheme ( 101 )). In addition, using a zero- 


knowledge proof-of-knowledge (j81j; [20; 1751) . each party also 


proves that it knows its own input; that is, that it can 
decommit to the commitment it sent. (These zero-knowledge 
proofs-of-knowledge are conducted sequentially to prevent 
dishonest parties from setting their inputs in a way that 
depends on inputs of honest parties; a more round-efficient 
method was presented in drill .1 

(2) Generation of local random tapes: Next, all parties jointly 
generate a sequence of random bits for each party such 
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that only this party knows the outcome of the random 
sequence generated for it, but everybody gets a commitment 
to this outcome. These sequences will be used as the random- 
inputs (i.e., sequence of coin tosses) for the original protocol. 
Each bit in the random-sequence generated for Party X is 
determined as the exclusive-or of the outcomes of instances 
of an (augmented) coin-tossing protocol (cf. (128l ) and (167l . 
Sec. 7.4.3.5)) that Party X plays with each of the other par¬ 
ties. The latter protocol provides the other parties with a 
commitment to the outcome obtained by Party X. 

(3) Effective prevention of premature termination : In addition, 
when compiling (the passively-secure protocol to an actively- 
secure protocol) for the model that allows the adversary to 
control only a minority of the parties, each party shares its 
input and random-input with all other parties using a “Ver¬ 
ifiable Secret Sharing” (VSS) protocol (cf. (43) and (67, 
Sec. 7.5.5.1)). Loosely speaking, a VSS protocol allows a 
secret to be shared in a way that enables each participant 
to verify that the share it got fits the publicly posted infor¬ 
mation, which includes (on top of the commitments posted 
in Steps 1 and 2) commitments to all shares. The use of VSS 
guarantees that if Party X prematurely suspends the exe¬ 
cution, then the honest parties can together reconstruct all 
Party X’s secrets and carry on the execution while playing 
its role. This step effectively prevents premature termina¬ 
tion, and is not needed in a model that does not consider 
premature termination a breach of security. 

(4) Step-by-step emulation of the original protocol : After all the 
above steps were completed, we turn to the main step in 
which the new protocol emulates the original one. In each 
step, each party augments the message determined by the 
original protocol with a zero-knowledge proof that asserts 
that the message was indeed computed correctly. Recall that 
the next message (as determined by the original protocol) 
is a function of the sender’s own input, its random-input, 
and the messages it has received so far (where the latter are 
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known to everybody because they were sent over a broadcast 
channel). Furthermore, the sender’s input is determined by 
its commitment (as sent in Step 1), and its random-input 
is similarly determined (in Step 2). Thus, the next message 
(as determined by the original protocol) is a function of pub¬ 
licly known strings (i.e., the said commitments as well as the 
other messages sent over the broadcast channel). Moreover, 
the assertion that the next message was indeed computed 
correctly is an NP-assertion, and the sender knows a corre¬ 
sponding NP-witness (i.e., its own input and random-input as 
well as the corresponding decommitment information). Thus, 
the sender can prove in zero-knowledge (to each of the other 
parties) that the message it is sending was indeed computed 
according to the original protocol. 


The above compilation was first outlined in (75); 
description and full proofs appear in (1631; |67). 


74). A detailed 


A secure coin-tossing protocol. Using a commitment scheme 
(see Section 14.31) . we outline a secure (ordinary as opposed to aug¬ 
mented) coin-tossing protocol, which originates in (28). 


Step Cl: Party 1 uniformly selects cr 6 {0,1} and sends Party 2 a 
commitment, denoted c, to a. 

Step C2: Party 2 uniformly selects a' e {0,1}, and sends o' to 
Party 1. 

Step C3: Party 1 outputs the value a © a', and sends a along with 
the decommitment information, denoted d, to Party 2. 

Step C4 '• Party 2 checks whether or not (a, d ) fit the commitment c it 
has obtained in Step 1. It outputs a® a' if the check is satisfied 
and halts with output T otherwise (indicating that Party 1 has 
essentially aborted the protocol prematurely). 

Outputs: Party 1 always outputs b = f a ® a', whereas Party 2 either 
outputs 6 or 1. 


Intuitively, Steps C1-C2 may be viewed as “tossing a coin into the 
well”. At this point (i.e., after Step C2) the value of the coin is deter- 
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mined (essentially as a random value), but only one party (i.e., Party 1) 
“can see” (i.e., knows) this value. Clearly, if both parties are honest 
then they both output the same uniformly chosen bit, recovered in 
Steps C3 and C4, respectively. Intuitively, each party can guarantee 
that the outcome is uniformly distributed, and Party 1 can cause pre¬ 
mature termination by improper execution of Step 3. Formally, we have 
to show how the effect of every real-model adversary can be simulated 
by an adequate ideal-model adversary (which is allowed premature ter¬ 
mination). This is done in (67, Sec. 7.4.3.1). 


7.4 Concurrent execution of protocols 

The definitions and results surveyed so far refer to a setting in which, 
at each time, only a single execution of a cryptographic protocol takes 
place (or only one execution may be controlled by the adversary). 
In contrast, in many distributed settings (e.g., the Internet), many 
executions are taking place concurrently (and several of them may 
be controlled by the same adversary). Furthermore, it is undesirable 
(and sometimes even impossible) to coordinate these executions (so to 
effectively enforce a single-execution setting). Still, the definitions and 
results obtained in the single-execution setting serve as a good starting 
point for the study of security in the setting of concurrent executions. 

As in the case of stand-alone security, the notion of zero-knowledge 
provides a good test case for the study of concurrent security. Indeed, 
in order to demonstrate the security issues arising from concurrent 
execution of protocols, we consider the concurrent execution of zero- 
knowledge protocols. Specifically, we consider a party P holding a ran¬ 
dom (or rather pseudorandom) function / : {0, l} 2 " —>■ {0,l} n , and 
willing to participate in the following protocol (with respect to secu¬ 
rity parameter n) @ The other party, called A for adversary, is supposed 
to send P a binary value v G {1,2} specifying which of the following 
cases to execute: 


In fact, assuming that P shares a pseudorandom function / with his friends (as explained 
in Section not . the above protocol is an abstraction of a natural “mutual identification” 
protocol. (The example is adapted from 0)0 
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For v = 1: Party P uniformly selects a G {0,l} n , and sends it to 
A. which is supposed to reply with a pair of n-bit long strings, 
denoted (j3, 7 ). Party P checks whether or not /(a/3) = 7 . In 
case equality holds, P sends A some secret information (e.g., 
the secret-key corresponding to P’s public-key). 

For v = 2: Party A is supposed to uniformly select a G {0, l} n , and 
sends it to P, which selects uniformly /3 G {0,l} n , and replies 
with the pair (/3, /(a/3)). 


Observe that P’s strategy (in each case) is zero-knowledge (even w.r.t 
auxiliary-inputs as defined in Definition 14.11) : Intuitively, if the adver¬ 
sary A chooses the case v = 1 , then it is infeasible for A to guess a 
passing pair (/3, 7 ) with respect to a random a selected by P. Thus, 
except with negligible probability (when it may get secret informa¬ 
tion), A does not obtain anything from the interaction. On the other 
hand, if the adversary A chooses the case v = 2 , then it obtains a pair 
that is indistinguishable from a uniformly selected pair of ?r-bit long 
strings (because [3 is selected uniformly by P, and for any a the value 
/(a/3) looks random to A). In contrast, if the adversary A can conduct 
two concurrent executions with P, then it may learn the desired secret 
information: In one session, A sends v = 1 while in the other it sends 
v = 2. Upon receiving P’s message, denoted a, in the first session, 
A sends it as its own message in the second session, obtaining a pair 
(/?, /(a/3)) from P’s execution of the second session. Now, A sends the 
pair (/3, /(a/3)) to the first session of P, this pair passes the check, and 
so A obtains the desired secret. 

An attack of the above type is called a relay attack: During such an 
attack the adversary just invokes two executions of the protocol and 
relays messages between them (without any modification). However, 
in general, the adversary in a concurrent setting is not restricted to 
relay attacks. For example, consider a minor modification to the above 
protocol so that, in case v = 2, party P replies with (say) the pair 
((3, f(a/3)), where a = a© ll a l, rather than with (/3, /(a/3)). The modi¬ 
fied strategy P is zero-knowledge and it also withstands a relay attack, 
but it can be “abused” easily by a more general concurrent attack. 
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The above example is merely the tip of an iceberg, but it suffices for 
introducing the main lesson: an adversary attacking several concurrent 
executions of the same protocol may he able to cause more damage than 
by attacking a single execution (or several sequential executions) of the 
same protocol. One may say that a protocol is concurrently secure if 
whatever the adversary may obtain by invoking and controlling parties 
in real concurrent executions of the protocol is also obtainable by a 
corresponding adversary that controls corresponding parties making 
concurrent functionality calls to a trusted party (in a corresponding 
ideal model) 0 More generally, one may consider concurrent executions 
of many sessions of several protocols, and say that a set of protocols is 
concurrently secure if whatever the adversary may obtain by invoking 
and controlling such real concurrent executions is also obtainable by 
a corresponding adversary that invokes and controls concurrent calls 
to a trusted party (in a corresponding ideal model). Consequently, a 
protocol is said to be secure with respect to concurrent compositions if 
adding this protocol to any set of concurrently secure protocols yields 
a set of concurrently secure protocols. 

A much more appealing approach was recently suggested by 
Canetti (34). Loosely speaking, Canetti suggests to consider a protocol 
to be secure (called environmentally-secure (or Universally Compos- 
able secure (34))) only if it remains secure when executed within any 
(feasible) environment. Following the simulation paradigm, we get the 
following definition: 


Definition 7.2. (environmentally-secure protocols (34 ) ~ a rough 
sketch): Let / be an m- ary functionality and II be an m-party pro¬ 
tocol, and consider the following real and ideal models. 


' One specific concern (in such a concurrent setting) is the ability of the adversary to “non- 
trivially correlate the outputs” of concurrent executions. This ability, called malleability , 
was first investigated by Dolev, Dwork and Naor (THoh . We comment that providing a 
general definition of what “correlated outputs” means seems very challenging (if at all 
possible). Indeed the focus of JHol) is on several important special cases such as encryption 
and commitment schemes. 





7.4. Concurrent execution of protocols 111 


In the real model the adversary controls some of the parties in an exe¬ 
cution of II and all parties can communicate with an arbitrary 
probabilistic polynomial-time process, which is called an envi¬ 
ronment ('and possibly represents other executions of various 
protocols that are taking place concurrently,). Honest parties 
only communicate with the environment before the execution 
starts and when it ends; they merely obtain their inputs from 
the environment and pass their outputs to it. In contrast, dis¬ 
honest parties may communicate freely with the environment, 
concurrently to the entire execution of n. 

In the ideal model the (simulating) adversary controls the same par¬ 
ties, which use an ideal (trusted-party) that behaves accord¬ 
ing to the functionality / (as in Section 17.1.21) . All parties 
can communicate with the (same) environment (as in the real 
model). Indeed, the dishonest parties may communicate exten¬ 
sively with the environment before and after their single com¬ 
munication with the trusted party. 

We say that n is an environmentally-secure protocol for computing / if 
for every probabilistic polynomial-time adversary A in the real model 
there exists a probabilistic polynomial-time adversary A 1 controlling the 
same parties in the ideal model such that no probabilistic polynomial¬ 
time environment can distinguish the case in which it is accessed by 
the parties in the real execution from the case it is accessed by parties 
in the ideal model. 


As hinted above, the environment may account for other executions 
of various protocols that are taking place concurrently to the main exe¬ 
cution being considered. The definition requires that such environments 
cannot distinguish the real execution from an ideal one. This means 
that anything that the real adversary (i.e., operating in the real model) 
gains from the execution and some environment, can be also obtained 
by an adversary operating in the ideal model and having access to the 
same environment. Indeed, Canetti proves that environment ally-secure 
protocols are secure with respect to concurrent compositions (1341 ). 

It is known is that environmentally-secure protocols for any func¬ 
tionality can be constructed for settings in which more than two-thirds 
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of the active parties are honest (I34J ). This holds unconditionally for the 
private channel model, and under standard assumptions (e.g., allowing 
the construction of public-key encryption schemes) for the standard 
model (i.e., without private channel). The immediate consequence of 
this result is that general environment ally-secure multi-party computa¬ 
tion is possible, provided that more than two-thirds of the parties are 
honest. 

In contrast, general environmentally-secure two-party computation 
is not possible (in the standard sense) o Still, one can salvage general 
environment ally-secure two-party computation in the following reason¬ 
able model: Consider a network that contains servers that are willing 
to participate (as “helpers”, possibly for a payment) in computations 
initiated by a set of (two or more) users. Now, suppose that two users 
wishing to conduct a secure computation can agree on a set of servers so 
that each user believes that more than two-thirds of the servers (in this 
set) are honest. Then, with the active participation of this set of servers, 
the two users can compute any functionality in an environment ally- 
secure manner. 

Other reasonable models where general environmentally-secure two- 
party computation is possible include the common random-string 
(CRS) model (41) and variants of the public-key infrastructure (PKI) 
model (111). In the CRS model, all parties have access to a univer¬ 
sal random string (of length related to the security parameter). We 
stress that the entity trusted to post this universal random string is 
not required to take part in any execution of any protocol, and that all 
executions of all protocols may use the same universal random string. 
The PKI models considered in 0 ) require that each party deposits a 
public-key with a trusted center, while proving knowledge of a corre¬ 
sponding private-key. This proof may be conducted in zero-knowledge 
during special epochs in which no other activity takes place. 


7.5 Concluding remarks 

In Sections 17. 1 117.21 we have mentioned a host of definitions of secu¬ 
rity and constructions for multi-party protocols (especially for the case 

8 Of course, some specific two-party computations do have environmentally-secure protocols. 
See 134) for several important examples (e.g., key exchange). 
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of more than two parties). Furthermore, some of these definitions are 
not comparable to others (i.e., they neither imply the others nor are 
implies by them), and there seems to be no single definition that may 
be crowned as the central one. 

For example, in Sections 17.1.21 and 17.1.31 we have presented two 
alternative definitions of “secure multi-party protocols”, one requiring 
an honest majority and the other allowing abort. These definitions are 
incomparable and there is no generic reason to prefer one over the other. 
Actually, as mentioned in Section I7.1.21 one could formulate a natural 
definition that implies both definitions (i.e., waiving the bound on the 
number of dishonest parties in Definition 17.11) . Indeed, the resulting 
definition is free of the annoying restrictions that were introduced in 
each of the two aforementioned definitions; the “only” problem with 
the resulting definition is that it cannot be satisfied (in general). Thus, 
for the first time in this primer, we have reached a situation in which a 
natural (and general) definition cannot be satisfied, and we are forced 
to choose between two weaker alternatives, where each of these alter¬ 
natives carries fundamental disadvantages. 

In general, Section [7] carries a stronger flavor of compromise (i.e., 
recognizing inherent limitations and settling for a restricted meaningful 
goal) than previous sections. In contrast to the impression given in other 
parts of this primer, it is now obvious that we cannot get all that we 
may want (see Section El. Instead, we should study the alternatives, 
and go for the one that best suits our real needs. 

Indeed, as stated in Section fTTTl the fact that we can define a crypto¬ 
graphic goal does not mean that we can satisfy it as defined. In case 
we cannot satisfy the initial definition, we should search for relaxations 
that can be satisfied. These relaxations should be defined in a clear 
manner so that it would be obvious what they achieve (and what they 
fail to achieve). Doing so will allow a sound choice of the relaxation to 
be used in a specific application. This seems to be a good point to end 
the current primer. 


A good compromise is one in which 
the most important interests 
of all parties are satisfied. 
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